On Fri, May 8, 2015 at 10:13 AM, Anne van Kesteren wrote:
> On Fri, May 8, 2015 at 7:09 PM, Tab Atkins Jr. 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
On Fri, May 8, 2015 at 7:09 PM, Tab Atkins Jr. 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.
--
https://annevank
On Fri, May 8, 2015 at 9:09 AM, Boris Zbarsky 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 stuff.
L
On Thu, May 7, 2015 at 10:42 PM, Anne van Kesteren wrote:
> On Thu, May 7, 2015 at 11:23 PM, Tab Atkins Jr. wrote:
>> Well, beyond the existing conflicts of
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)
characte
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 case-sensiti
On Thu, May 7, 2015 at 11:23 PM, Tab Atkins Jr. wrote:
> Well, beyond the existing conflicts of
On Thu, May 7, 2015 at 2:11 PM, Elliott Sprehn wrote:
> On Thu, May 7, 2015 at 2:09 PM, Boris Zbarsky 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
>>
On Thu, May 7, 2015 at 2:09 PM, Boris Zbarsky 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 a lowerca
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 mai
On Thu, May 7, 2015 at 8:26 AM, Boris Zbarsky wrote:
> Note that at least for 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 anyway, so that's not a bi
On Thu, May 7, 2015 at 4:16 AM, Rune Lillesveen 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 according to t
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, actually
On Thu, May 7, 2015 at 3:59 PM, 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 matc
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 equ
On Thu, May 7, 2015 at 2:13 PM, Roger Hågensen 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 complexity to t
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 ca
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:
foreignObject { color: red }
foreignobject { color:
18 matches
Mail list logo
