On Fri, 2008-02-08 at 15:21 +, Martin McEvoy wrote:
eg: we could use class data as a container for what we want to
include.
span class=vcard
span class=data
span class=fnFoo/span
/span
a class=email href=mailto:[EMAIL PROTECTED]email
[EMAIL
Hello Toby
On Fri, 2008-02-08 at 10:58 +, Toby A Inkster wrote:
Such that this:
p class=#foo bar #baz
x
/p
is considered equivalent to the following using current existing
include-
pattern:
p class=bar
a class=include
Paul Wilkins wrote:
Toby A Inkster wrote:
The order of the paragraphs doesn't have a special significance, yet
the paragraphs do have an inherent order. Similarly, the order of class
names within a class attribute don't have a special significance
attached to them by the HTML spec, but they
Ryan King wrote:
Toby A Inkster wrote:
It does claim that it's a set of class names, and in mathematical
parlance sets are unordered by definition, and must not contain
duplicates, but it's unlikely that the framers of the HTML 4.01 spec
intended the world set to be interpreted in that way
Paul Wilkins wrote:
If the ordering of class names were supposed to to have some special
significance, there would be further information about such a specific
order. In this case a lack of evidence points to no importance in the
order of the class names.
If the ordering of paragraphs were
On Feb 7, 2008 4:36 AM, Toby A Inkster [EMAIL PROTECTED] wrote:
The order of the paragraphs doesn't have a special significance, yet the
paragraphs do have an inherent order. Similarly, the order of class names
within a class attribute don't have a special significance attached to
them by the
Tantek =?ISO-8859-1?B?xw==?=elik wrote:
1. class is an unordered set of values per HTML4. introducing ordering
is a non-starter both from a violation of HTML4 spec perspective and
likely requiring of rewriting HTML4 parsers to maintain an ordering
where they currently don't.
A reading of
On Feb 5, 2008, at 8:23 AM, Toby A Inkster wrote:
Tantek =?ISO-8859-1?B?xw==?=elik wrote:
1. class is an unordered set of values per HTML4. introducing
ordering
is a non-starter both from a violation of HTML4 spec perspective and
likely requiring of rewriting HTML4 parsers to maintain an
On Feb 6, 2008 12:00 PM, Ryan King [EMAIL PROTECTED] wrote:
Specs aren't generally written in layman's terms.
If the ordering of class names were supposed to to have some special
significance, there would be further information about such a specific
order. In this case a lack of evidence points
pWe have three branches in span class=locality
id=ldnLondon/span, including our head office in
span class=locality id=kenKensington/span:/p
ul
li class=adr #ldn
span class=street-address123 Oxford Street/span
/li
li class=adr #ken #ldn
span class=street-address5 Kensington High
Toby A Inkster wrote:
The order of the space-delimited class attributes should be considered
significant -- that is, in foo class=bar #baz the content referred
to by #baz is logically included as the last child of the foo element,
but in foo class=#baz bar, it is logically included as the
In message [EMAIL PROTECTED], Toby A Inkster
[EMAIL PROTECTED] writes
The order of the space-delimited class attributes should be considered
significant -- that is, in foo class=bar #baz the content referred
to by #baz is logically included as the last child of the foo
element, but in foo
On Sun, 2008-02-03 at 19:46 +, Andy Mabbett wrote:
In message [EMAIL PROTECTED], Toby A Inkster
[EMAIL PROTECTED] writes
The order of the space-delimited class attributes should be considered
significant -- that is, in foo class=bar #baz the content referred
to by #baz is logically
In message [EMAIL PROTECTED], Toby A Inkster
[EMAIL PROTECTED] writes
The order of the space-delimited class attributes should be considered
significant -- that is, in foo class=bar #baz the content referred
to by #baz is logically included as the last child of the foo element,
but in foo
On Sun, 2008-02-03 at 20:40 +, Martin McEvoy wrote:
foo id=me class=fnMartin McEvoy/foo
bar class=[EMAIL PROTECTED]http://wherever.com//bar
No :( too verbose anyway:
div class=vcard
span id=me class=fnMartin McEvoy/span
br /a class=url org href=http://someurl.co.uk/;WebOrganics/a
/div
On Sun, 2008-02-03 at 21:35 +, Martin McEvoy wrote:
On Sun, 2008-02-03 at 20:40 +, Martin McEvoy wrote:
foo id=me class=fnMartin McEvoy/foo
bar class=[EMAIL PROTECTED]http://wherever.com//bar
No :( too verbose anyway:
A solution may be to remove our own anti-patterns
On 2/3/08 4:34 AM, Toby A Inkster [EMAIL PROTECTED] wrote:
Toby A Inkster wrote:
The order of the space-delimited class attributes should be considered
significant -- that is, in foo class=bar #baz the content referred
to by #baz is logically included as the last child of the foo element,
Toby A Inkster wrote:
For addresses, the order of the included elements is probably not
important. When it comes to, say, printing an envelope, we all know that
the street address comes before the locality. Parsers can have this
knowledge hard-coded.
This is probably true, although note this
18 matches
Mail list logo
