Bug 128882

Summary: When applying style, attribute value matching should be case sensitive for SVG
Product: WebKit Reporter: Benjamin Poulain <benjamin>
Component: New BugsAssignee: Benjamin Poulain <benjamin>
Status: RESOLVED FIXED    
Severity: Normal CC: allan.jensen, commit-queue, esprehn+autocc, glenn, gyuyoung.kim, koivisto, krit, macpherson, menard
Priority: P2    
Version: 528+ (Nightly build)   
Hardware: Unspecified   
OS: Unspecified   
Attachments:
Description Flags
Patch none

Benjamin Poulain
Reported 2014-02-15 20:54:50 PST
When applying style, attribute value matching should be case sensitive for SVG
Attachments
Patch (9.01 KB, patch)
2014-02-15 20:58 PST, Benjamin Poulain
no flags
Benjamin Poulain
Comment 1 2014-02-15 20:58:46 PST
Andreas Kling
Comment 2 2014-02-16 10:55:40 PST
Comment on attachment 224314 [details] Patch r=me, great catch!
Benjamin Poulain
Comment 3 2014-02-16 19:14:38 PST
Comment on attachment 224314 [details] Patch Clearing flags on attachment: 224314 Committed r164203: <http://trac.webkit.org/changeset/164203>
Benjamin Poulain
Comment 4 2014-02-16 19:14:45 PST
All reviewed patches have been landed. Closing bug.
Dirk Schulze
Comment 5 2014-02-17 04:51:07 PST
I do not disagree that XML and SVG require case sensitiveness. So according to standards this is correct for now. However, we try to harmonize SVG and HMTL where ever possible. Even the specification is slowly going into this direction. I am not sure if case sensitiveness for SVG is the right signal here.
Benjamin Poulain
Comment 6 2014-02-17 11:16:32 PST
(In reply to comment #5) > However, we try to harmonize SVG and HMTL where ever possible. Even the specification is slowly going into this direction. I am not sure if case sensitiveness for SVG is the right signal here. In the case of SelectorChecker, it is only doing case-insensitive value matching for a handful of legacy attributes. It is compatibility feature for old content. This case-insensitive exception is nonsense in my opinion. It is impossible to understand for authors (the list is arbitrary and poorly documented) and those attributes are slower. We should aim toward removing this from HTML instead of adding it to SVG.
Dirk Schulze
Comment 7 2014-02-18 00:40:35 PST
(In reply to comment #6) > (In reply to comment #5) > > However, we try to harmonize SVG and HMTL where ever possible. Even the specification is slowly going into this direction. I am not sure if case sensitiveness for SVG is the right signal here. > > In the case of SelectorChecker, it is only doing case-insensitive value matching for a handful of legacy attributes. It is compatibility feature for old content. > > This case-insensitive exception is nonsense in my opinion. It is impossible to understand for authors (the list is arbitrary and poorly documented) and those attributes are slower. We should aim toward removing this from HTML instead of adding it to SVG. Are there ambitions on WHATWG or somewhere else to drive this forward? Just to make it clear, I care less about case sensitiveness but more about consistency. Authors shouldn't be surprised because the same code that works in HTML doesn't work in SVG and vice versa. This is particularly bad for inline SVG embedded in HTML directly.
Benjamin Poulain
Comment 8 2014-02-18 00:57:07 PST
(In reply to comment #7) > Are there ambitions on WHATWG or somewhere else to drive this forward? Just to make it clear, I care less about case sensitiveness but more about consistency. Authors shouldn't be surprised because the same code that works in HTML doesn't work in SVG and vice versa. This is particularly bad for inline SVG embedded in HTML directly. There is a spec, it is followed by Firefox (and probably IE) -> we should match the spec. You think there is matter to change the spec. It can go two ways: update SVG or fix HTML. I am in favor of fixing HTML. I do not participate in WHATWG so it is up to you if you want the change. If you change the SVG spec (and Mozilla/Microsoft are on board), I am totally ok with "unfixing" this bug.
Note You need to log in before you can comment on or make changes to this bug.