On 2015-05-07 15:59, Boris Zbarsky wrote:
On 5/7/15 7:16 AM, Rune Lillesveen wrote:
This adds an implementation complexity to type selector matching.
What's the rationale for matching the selector case-sensitively in the
svg case?
The idea is to allow the selector match to be done
On Fri, May 8, 2015 at 7:09 PM, Tab Atkins Jr. jackalm...@gmail.com wrote:
I don't think ascii case-insensitivity is a mistake here.
(ASCII) case-insensitivity is a mistake. JavaScript doesn't have it
and wherever we do have it it's sticking out as sore thumb with a
dozen subtleties attached.
On Thu, May 7, 2015 at 10:42 PM, Anne van Kesteren ann...@annevk.nl wrote:
On Thu, May 7, 2015 at 11:23 PM, Tab Atkins Jr. jackalm...@gmail.com wrote:
Well, beyond the existing conflicts of style, script, and a.
(font too, but that's dropped from SVG2, so who cares.)
textArea is out too?
On Fri, May 8, 2015 at 10:13 AM, Anne van Kesteren ann...@annevk.nl wrote:
On Fri, May 8, 2015 at 7:09 PM, Tab Atkins Jr. jackalm...@gmail.com wrote:
I don't think ascii case-insensitivity is a mistake here.
(ASCII) case-insensitivity is a mistake. JavaScript doesn't have it
and wherever we
On 5/8/15 11:56 AM, Roger Hågensen wrote:
One way to cheapen the computational cost is to have partial case
insensitive matching.
If you're walking the string at all, you have already lost in terms of
performance for this stuff.
If (character = $0041) And (character = $005A)
character
On Fri, May 8, 2015 at 9:09 AM, Boris Zbarsky bzbar...@mit.edu wrote:
On 5/8/15 11:56 AM, Roger Hågensen wrote:
One way to cheapen the computational cost is to have partial case
insensitive matching.
If you're walking the string at all, you have already lost in terms of
performance for this
On Thu, May 7, 2015 at 2:11 PM, Elliott Sprehn espr...@chromium.org wrote:
On Thu, May 7, 2015 at 2:09 PM, Boris Zbarsky bzbar...@mit.edu wrote:
On 5/7/15 5:07 PM, Tab Atkins Jr. wrote:
I believe the SVGWG is fine with a parsing-based approach, exactly
like what HTML does. An SVG element
On Thu, May 7, 2015 at 2:13 PM, Roger Hågensen rh_wha...@skuldwyrm.no wrote:
On 2015-05-07 13:16, Rune Lillesveen wrote:
Currently, the HTML spec says that type selectors matches case
sensitively for non-html elements like svg elements in html documents
...
This adds an implementation
Currently, the HTML spec says that type selectors matches case
sensitively for non-html elements like svg elements in html documents
[1]. So according to the spec, and the implementation in Gecko, the
rules below matches according to the prose:
!DOCTYPE html
style
foreignObject { color: red }
On Thu, May 7, 2015 at 11:23 PM, Tab Atkins Jr. jackalm...@gmail.com wrote:
Well, beyond the existing conflicts of style, script, and a.
(font too, but that's dropped from SVG2, so who cares.)
textArea is out too?
With respect to case-insensitive matching, I don't really understand
why we
On 5/7/15 7:16 AM, Rune Lillesveen wrote:
This adds an implementation complexity to type selector matching.
What's the rationale for matching the selector case-sensitively in the
svg case?
The idea is to allow the selector match to be done case-sensitively in
all cases so it can be done as
On Thu, May 7, 2015 at 8:26 AM, Boris Zbarsky bzbar...@mit.edu wrote:
Note that at least for textArea this matters, in that you could suddenly
have selectors that are not meant to match it start matching it.
That's not part of SVG1.1 or SVG2; it's not supported on most (all?)
major browsers
On 5/7/15 5:07 PM, Tab Atkins Jr. wrote:
I believe the SVGWG is fine with a parsing-based approach, exactly
like what HTML does. An SVG element created with mixed casing, or
imported from an XML document, might not match a lowercase tagname
selector, but SVG written in HTML will.
Hmm. The
On Thu, May 7, 2015 at 2:09 PM, Boris Zbarsky bzbar...@mit.edu wrote:
On 5/7/15 5:07 PM, Tab Atkins Jr. wrote:
I believe the SVGWG is fine with a parsing-based approach, exactly
like what HTML does. An SVG element created with mixed casing, or
imported from an XML document, might not match
On Thu, May 7, 2015 at 4:16 AM, Rune Lillesveen r...@opera.com wrote:
Currently, the HTML spec says that type selectors matches case
sensitively for non-html elements like svg elements in html documents
[1]. So according to the spec, and the implementation in Gecko, the
rules below matches
On 5/7/15 10:53 AM, Rune Lillesveen wrote:
So there's no author-rationale here?
Well... that depends.
The way things used to work before SVG-in-HTML existed is that selector
matching was case-sensitive in SVG and apppeared case-insensitive in
HTML. I say appeared because it wasn't,
On Thu, May 7, 2015 at 3:59 PM, Boris Zbarsky bzbar...@mit.edu wrote:
On 5/7/15 7:16 AM, Rune Lillesveen wrote:
This adds an implementation complexity to type selector matching.
What's the rationale for matching the selector case-sensitively in the
svg case?
The idea is to allow the
On 2015-05-07 13:16, Rune Lillesveen wrote:
Currently, the HTML spec says that type selectors matches case
sensitively for non-html elements like svg elements in html documents
...
This adds an implementation complexity to type selector matching.
What's the rationale for matching the selector
18 matches
Mail list logo
