Re: [whatwg] Attributes vs. Elements

[Daniel Glazman]

On 13/03/2007 07:29, Karl Dubost wrote:


It comes with test cases and implementations.


I disagree 100%. Pragmatism is a state of mind, not a process.
Tests and implementations can be successful on a spec, and the spec
can remain a failure because it lacks pragmatism.

Re: [whatwg] Attributes vs. Elements

[Daniel Glazman]

On 13/03/2007 07:26, Ian Hickson wrote:

Don't worry, the WHATWG basic principles put pragmatism first. It's the 
only way to get a spec implemented, and without implementations, specs are 
somewhat academic.


It's also the only way to do something not totally disconnected from
users' needs...

Re: [whatwg] Attributes vs. Elements

[Karl Dubost]

Le 13 mars 2007 à 15:23, Daniel Glazman a écrit :

I would add a major principle, rarely explicit : PRAGMATISM.
Sometimes purity calls for an element while browser implems
call for an attribute ; or the contrary. And even if implem
issues should not apply in theory, they do apply in real life...


It comes with test cases and implementations.
We can say a lot of things, and I'm pretty sure all interesting (at  
least in certain spheres), but in the end the the reality check is


	someone who can use the feature in its favorite tools in an  
interoperable way.


modulo the "there are many kind of someone".

--
Karl Dubost - http://www.w3.org/People/karl/
W3C Conformance Manager, QA Activity Lead
  QA Weblog - http://www.w3.org/QA/
 *** Be Strict To Be Cool ***

Re: [whatwg] Attributes vs. Elements

[Ian Hickson]

On Tue, 13 Mar 2007, Daniel Glazman wrote:
> 
> I would add a major principle, rarely explicit : PRAGMATISM. Sometimes 
> purity calls for an element while browser implems call for an attribute 
> ; or the contrary. And even if implem issues should not apply in theory, 
> they do apply in real life...

Don't worry, the WHATWG basic principles put pragmatism first. It's the 
only way to get a spec implemented, and without implementations, specs are 
somewhat academic.

-- 
Ian Hickson   U+1047E)\._.,--,'``.fL
http://ln.hixie.ch/   U+263A/,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

Re: [whatwg] Attributes vs. Elements

[Daniel Glazman]

On 13/03/2007 07:12, Karl Dubost wrote:


more references, food for thoughts.

* Markup design: elements or attributes?
  http://annevankesteren.nl/2004/07/markup

* Principles of XML design: When to use elements versus attributes
  http://www-128.ibm.com/developerworks/xml/library/x-eleatt.html

* SGML/XML: Using Elements and Attributes
  http://www.oasis-open.org/cover/elementsAndAttrs.html


I would add a major principle, rarely explicit : PRAGMATISM.
Sometimes purity calls for an element while browser implems
call for an attribute ; or the contrary. And even if implem
issues should not apply in theory, they do apply in real life...

Re: [whatwg] Attributes vs. Elements

[Karl Dubost]

Le 13 mars 2007 à 03:25, Maciej Stachowiak a écrit :
The recent discussion of possibly making the href attribute global  
brings to mind a broader issue. To what extent should semantics and  
behavior belong to specific elements, and to what extent should  
they be carried by global attributes that can apply to any element?


more references, food for thoughts.

* Markup design: elements or attributes?
  http://annevankesteren.nl/2004/07/markup

* Principles of XML design: When to use elements versus attributes
  http://www-128.ibm.com/developerworks/xml/library/x-eleatt.html

* SGML/XML: Using Elements and Attributes
  http://www.oasis-open.org/cover/elementsAndAttrs.html

--
Karl Dubost - http://www.w3.org/People/karl/
W3C Conformance Manager, QA Activity Lead
  QA Weblog - http://www.w3.org/QA/
 *** Be Strict To Be Cool ***

Re: [whatwg] Attributes vs. Elements

[Daniel Glazman]

On 12/03/2007 21:53, [EMAIL PROTECTED] wrote:


XHTML2 moves a lot of semantics and behavior from elements to global
attributes. For example, href can turn any element into a hyperlink,
and src can turn any element into an image.


I liked the href adding a link to any object, but the src, I don't care
for.  I can already set a background image on an element to "turn it into
an image." 


CSS 3 content property can do it.

Re: [whatwg] Attributes vs. Elements

[whatwg]

ddailey wrote:
> The ease of using DOM methods to find tags, as opposed to attributes,
> tends  to suggest that all things having href's should be easily
> findable by  script.  works nicely for that, but would the
> availability of a  document.links array then include all things with
> href's?

In JavaScript, document.links would work, though I've been indoctrinated
into the modern DOM camp and like to use
document.getElementsByTagName("a").  I try to avoid DOM 0 style
collections, but for things like form validation, I end up using the
.elements collection frequently.  I'm sure I could adjust my way of
thinking if I needed to.

My gripe, however, was with CSS attribute selectors.[1]  I didn't really
make that clear.  IE 6 doesn't do them.  However, as someone pointed out,
something like td:link would work.  I wouldn't need td[href] to get at
"all tds with hrefs".  Assuming that is true, and it had support from the
4 major browsers, the href-on-all-attributes would work pragmatically.

If it would make sense semantically / ideologically, I'm still unsure.  I
don't know if the existence of the anchor element was lack of foresight or
if it has a real semantic meaning like em or strong that is independent of
the href.

[1] http://www.w3.org/TR/CSS21/selector.html#attribute-selectors

Re: [whatwg] Attributes vs. Elements

[Andrew Fedoniouk]

- Original Message - 
From: "Nicholas Shanks" <[EMAIL PROTECTED]>
To: "Andrew Fedoniouk" <[EMAIL PROTECTED]>
Cc: "WHATWG List" <[EMAIL PROTECTED]>
Sent: Monday, March 12, 2007 12:59 PM
Subject: Re: [whatwg] Attributes vs. Elements


| On 12 Mar 2007, at 20:19, Andrew Fedoniouk wrote:
| 
| > Case:
| > xyz
| > xyz-xyz-xyz
| > is perfectly valid from some abstract semantic machine
| > point of view but for human these two cells are not
| > equal. At least hit area is different. And visual perception too.
| 
| All you need to do is add this to your CSS:
| 
| td > a:link { display: block; }

display: block does not work in this case.

It should be something close to this:
a:link { display: block; width: 100%; height:100%; }
but as you know width: 100%; height:100%;  will 
not work in presence of borders and absence of 
explicit definitions of heights and widths in parents.

In general declaration of { display: block; } for
naturally inline elements does not work well in modern CSS
implementations.

Sidenote: 
Flex units I am using [1,2] may help in this case:
a:link { display: block; border: 1px; width: 100%%; height:100%%; }
but CSS is not there yet.

| 
| and the whole cell content area will become clickable (i.e. the area  
| interior to the padding. don't use padding on the cell if you want to  
| run the clickable area up to the cell's border)

up to *but not including* the cell's border ?
and what about height? And what if vertical 
alignment is used? Too many unknowns.


| 
| > I do not really understand this too:
| > "browser implementations have an implementation class per element"
| 
| Most HTML implementations use a class hierarchy whereby each HTML  
| element is represented by a distinct subclass of some abstract base  
| element representation. To move href onto every element would require  
| moving the hyperlink functionality into that base class rather than  
| having it in the anchor subclass.

I think that this is a bit idealistic picture of what is going on in reality.

In my particular case DOM element is a single entitiy (class in C++).
But each DOM element may have mutiple behaviors attached.
That behaviors are handlers of events and are indeed various 
classes in C++ derived from common super class. 
So when you are asking DOM element to provide interface 
IHTMLAnchorElement for example it will try to find it 
in the chain of  all attached behaviors. And this chain is 
dynamic in principle. 
Again this is my particular architecture but I beleive other
HTML/CSS DOM implementations are close to that.

| 
| For some browsers this could be quite easy, for others it would be  
| deceptively difficult.

Well, HTML/CSS is not so easy thing in implementation.
I mean this fact does not stop UA vendors from development.

Andrew Fedoniouk.
http://terrainformatica.com

[1] Flex units in h-smile core http://terrainformatica.com/htmlayout/fspu.whtm
that is a generalization of "relative length units" used in HTML 4.01
[2] http://www.w3.org/TR/html401/types.html#type-length

Re: [whatwg] Attributes vs. Elements

[ddailey]

Robert wrote:

As I followed the thread, thinking about styling the element was the
clincher for me.  IE 6 doesn't support attribute based selectors.  So, I,
for one, couldn't use it until IE 6 (haven't tested attribute selectors in
IE 7, since I stopped using them in light of IE 6) lost most of it's
popularity.

The ease of using DOM methods to find tags, as opposed to attributes, tends 
to suggest that all things having href's should be easily findable by 
script.  works nicely for that, but would the availability of a 
document.links array then include all things with href's?


Tags are rather like nouns while attributes are rather like adjectives. 
Though those linguistic functions themselves are sometimes fluid.


A red circle -- A circular redness

There are known cross-cultural differences in which attributes define 
things, as for sorting. Navajo children, as I recall are more likely to sort 
by shape than Anglo-Americans. (Castaneda did some studies I think in the 
1960's). I do remember finding some of the part-of-speech distinctions in 
Navajo as counterintuitive.


Existing cultural relativity would tend to suggest no easy way of resolving 
the issue from a "cognitive" perspective.


It would seem then, best, in this case to default to the status quo.

ddailey 

Re: [whatwg] Attributes vs. Elements

[Dean Edridge]

On 12 Mar 2007, at 20:19, Andrew Fedoniouk wrote:


Case:
xyz
xyz-xyz-xyz
is perfectly valid from some abstract semantic machine
point of view but for human these two cells are not
equal. At least hit area is different. And visual perception too.


All you need to do is add this to your CSS:

td > a:link { display: block; }

and the whole cell content area will become clickable (i.e. the area 
interior to the padding. don't use padding on the cell if you want to 
run the clickable area up to the cell's border)


Is this normal behaviour according to the css spec? Because I use this 
method a lot but with li not td. I've never been able to get it to work 
on Opera though. I just thought that it was a case of Opera sticking to 
the spec and the others not. Once the cursor is over the text in a it's 
fine, but just hovering over the li does nothing.


Dean

Re: [whatwg] Attributes vs. Elements

[Ian Hickson]

On Mon, 12 Mar 2007, carmen wrote:
> >
> > Finally, I'd like to conclude with this reductio ad absurdum of the 
> > XHTML2 approach. If assigning behavior and semantics to attributes is 
> > so much better, why not just have a single  element:
> > 
> > My cat is really cute:  > src="mycat.jpeg">picture of my cat. Check out  > href="story.html">this hilarious story 
> > about her.
> 
> this is a valid approach. the next step is to factor out  and 
> simplify the syntax, preferably reusing JSON or the Relax-NG compact 
> syntax. then it would be more readable than either suggestion here.

Let's try to simplify it to XML, since XML is so popular. First, we
have to make the example a bit more explicit about what it is doing,
because right now it doesn't say what kind of link the src="" and
href="" attributes are creating (are they linking script? stylesheets?
a permalink for the page?):

  My cat is really cute: picture of my cat. Check out this hilarious story about her.

Now let's see what we can do about making it simpler...

could be 
could be 
could be 
could be 

...so we now have:

   My cat is really cute: picture of my
   cat. Check out this hilarious
   story about her.

...and we're nearly back to HTML!


> i also think its important that userdefined elements can inherit
> from other elements via the normal ECMAscript prototype idioms, so
> that one can eg, .property("dc:date").prototype = ,
> we'll always have semantic ambiguity and shoehorning of semantics
> into classnames and other attributes until theres the equivalent of
> the stylesheet providing referencable URIs describing any element -
> unless we want to stick to the boring world where theres only the
> elements that enough people could agree upon.

I really don't understand what you're proposing here. What is the
problem you are trying to solve?

-- 
Ian Hickson   U+1047E)\._.,--,'``.fL
http://ln.hixie.ch/   U+263A/,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

Re: [whatwg] Attributes vs. Elements

[Nicholas Shanks]

On 12 Mar 2007, at 20:19, Andrew Fedoniouk wrote:


Case:
xyz
xyz-xyz-xyz
is perfectly valid from some abstract semantic machine
point of view but for human these two cells are not
equal. At least hit area is different. And visual perception too.


All you need to do is add this to your CSS:

td > a:link { display: block; }

and the whole cell content area will become clickable (i.e. the area  
interior to the padding. don't use padding on the cell if you want to  
run the clickable area up to the cell's border)



Even now you can use get/setAttribute methods to get/set 'href'
attribute to any element.  So where do you see the problem?


But that doesn't make any of them clickable, because they are not  
anchor heads.



I do not really understand this too:
"browser implementations have an implementation class per element"


Most HTML implementations use a class hierarchy whereby each HTML  
element is represented by a distinct subclass of some abstract base  
element representation. To move href onto every element would require  
moving the hyperlink functionality into that base class rather than  
having it in the anchor subclass.


For some browsers this could be quite easy, for others it would be  
deceptively difficult.


- Nicholas.

smime.p7s
Description: S/MIME cryptographic signature

Re: [whatwg] Attributes vs. Elements

[carmen]

> Finally, I'd like to conclude with this reductio ad absurdum of the XHTML2 
> approach. If assigning behavior and semantics to attributes is so much 
> better, why not just have a single  element:
> 
> My cat is really cute: picture of 
> my cat. Check out this  role="emphasis">hilarious story about her.


this is a valid approach. the next step is to factor out  and simplify the 
syntax, preferably reusing JSON or the Relax-NG compact syntax. then it would 
be more readable than either suggestion here. 

i also think its important that userdefined elements can inherit from other 
elements via the normal ECMAscript prototype idioms, so that one can eg, 
.property("dc:date").prototype = , we'll always have semantic 
ambiguity and shoehorning of semantics into classnames and other attributes 
until theres the equivalent of the stylesheet providing referencable URIs 
describing any element - unless we want to stick to the boring world where 
theres only the elements that enough people could agree upon.

styling all the 'time' elements in the stylesheet is cake.. easier than 
deconstructing a microformat, or having to resort to crazy attribute matching 
xpath/regex..

fwiw, ive started doing this using HPricot serverside and JQuery clientside 
since i found microformats too limiting and both them and RDFa too verbose 
(they use attributes quite a bit instead of elements), i started writing 
webpages in pico and will do what it takes for that to continue in the day and 
age where i want semantic disambiguity/lossless-encoding for the elements.

> I find the HTML approach much more readable and more semantically clear:
> 
> My cat is really cute: . 
> Check out this hilarious story about 
> her.
> 
> Regards,
> Maciej
> 

Re: [whatwg] Attributes vs. Elements

[whatwg]

> XHTML2 moves a lot of semantics and behavior from elements to global
> attributes. For example, href can turn any element into a hyperlink,
> and src can turn any element into an image.

I liked the href adding a link to any object, but the src, I don't care
for.  I can already set a background image on an element to "turn it into
an image."  As I followed the thread you mentioned, I could see cases
where code would be cleaner to, for example, have an href in a heading
element.  That would solve some issues with inline elements holding block
elements (e.g. improperly adding an anchor to an entire h1 tag).

> - It's easier (and, in many implementations, more efficient) to style
> by tag name rather than by presence or absence of an attribute.

As I followed the thread, thinking about styling the element was the
clincher for me.  IE 6 doesn't support attribute based selectors.  So, I,
for one, couldn't use it until IE 6 (haven't tested attribute selectors in
IE 7, since I stopped using them in light of IE 6) lost most of it's
popularity.

After that, having the href in, say, an ordered list used for navigation
would save a few keystrokes.

> - Typically, browser implementations have an implementation class per
> element, but not a class per attribute, so putting primary semantics
> and behavior on an element instead of an attribute promotes clean
> implementation. Otherwise, all behavior ends up in the HTMLElement
> base class.

I can certainly see how this would trouble an implementor.  If it made
working with DOM objects (e.g. looping through an object's properties)
more tedious, developers would certainly care.

> Finally, I'd like to conclude with this reductio ad absurdum of the
> XHTML2 approach. If assigning behavior and semantics to attributes is
> so much better, why not just have a single  element:

While the href attribute is pretty common (lots of things need to be links
that are already wrapped in some kind of tag) and could simplify code, the
src element definitely seems to follow this reduction.

Having a few select attributes (specifically the href) applicable to all
tags could be useful.  But, I agree with you in the end.  The potential
problems and compromise of semantics is important enough either not to
have it, or not to use it if it is available if you desire a semantic
document (ignoring things like the title, lang, etc that really do need to
be available).

--
Robert Brodrecht 

Re: [whatwg] Attributes vs. Elements

[Andrew Fedoniouk]

- Original Message - 
From: "Maciej Stachowiak" <[EMAIL PROTECTED]>
To: "WHATWG Mailing List" <[EMAIL PROTECTED]>
Sent: Monday, March 12, 2007 10:25 AM
Subject: [whatwg] Attributes vs. Elements


| 
| 
| The recent discussion of possibly making the href attribute global  
| brings to mind a broader issue. To what extent should semantics and  
| behavior belong to specific elements, and to what extent should they  
| be carried by global attributes that can apply to any element?
| 
| XHTML2 moves a lot of semantics and behavior from elements to global  
| attributes. For example, href can turn any element into a hyperlink,  
| and src can turn any element into an image.
| 
| HTML5 has so far not taken this approach - elements generally remain  
| distinct, and new behaviors and semantics appear in the form of new  
| elements.
| 
| 
| In my opinion, it is usually better to put primary semantics on  
| elements rather than attributes. Here are a few reasons, in  
| approximate decreasing order of importance:
| 
| - An element is generally seen as a separate thing in itself, whereas  
| an attribute is just an attribute. So it is natural to think of an  
| element having more semantic strength than an attribute.

No objections in theory. But in practice...

As an example:  
Take a look on first column in first table here:
http://www.terrainformatica.com/forums/

Semantic (meaning) of elements there is 
"cell in the table" *and* "link". 

Current implementation: 
... is perfectly valid from 
abstract semantic automata analysing the Web but
it is wrong from human point of view - usability
and accessibility value of this solution is very low. 

For human  
( he/she consumes semantic in visual on-screen form)
this particular case should be rendered by: 


as all topics on the forum have equal semantic value.

Case: 
xyz
xyz-xyz-xyz
is perfectly valid from some abstract semantic machine 
point of view but for human these two cells are not
equal. At least hit area is different. And visual perception too.

So the question is: whose semantic meaning you are talking
about?

| 
| - Semantics that has associated behavior often has an associated DOM  
| API. For example, the A element has a number of attributes related to  
| its use as a hyperlink source, to programmatically retrieve or change  
| only part of the href URI. If any element could have the href  
| attribute, the options become omitting the API, adding it to all  
| elements, or (yuck) making it conditionally present on all elements  
| based on presence or absence of the attribute.

I do not understand paragraph above. 

Even now you can use get/setAttribute methods to get/set 'href' 
attribute to any element.  So where do you see the problem?

| 
| - It's easier (and, in many implementations, more efficient) to style  
| by tag name rather than by presence or absence of an attribute.

Why do you think that selector "a:link" is easier than ":link" ? 

| 
| - Typically, browser implementations have an implementation class per  
| element, but not a class per attribute, so putting primary semantics  
| and behavior on an element instead of an attribute promotes clean  
| implementation. Otherwise, all behavior ends up in the HTMLElement  
| base class.

I do not really understand this too:
"browser implementations have an implementation class per element"

Anyway attribute selectors are citizens of the same class as any 
others in CSS. What problem do you see with them?

| 
| 
| Finally, I'd like to conclude with this reductio ad absurdum of the  
| XHTML2 approach. If assigning behavior and semantics to attributes is  
| so much better, why not just have a single  element:
| 
| My cat is really cute: picture of my cat. Check out this hilarious story  
| about her.

True, any idea at some stage can become an absurd one.

This is also valid for the statement:
"Each DOM element has one and only one semantic meaning for
human". Reality is more colorful than that.

| 
| I find the HTML approach much more readable and more semantically clear:
| 
| My cat is really cute: . Check out this hilarious story  
| about her.

This particular example makes sense for me too. As I guess example
with my forum above for you.

Andrew Fedoniouk.
http://terrainformatica.com


| 
| Regards,
| Maciej
|

[whatwg] Attributes vs. Elements

[Maciej Stachowiak]

The recent discussion of possibly making the href attribute global  
brings to mind a broader issue. To what extent should semantics and  
behavior belong to specific elements, and to what extent should they  
be carried by global attributes that can apply to any element?


XHTML2 moves a lot of semantics and behavior from elements to global  
attributes. For example, href can turn any element into a hyperlink,  
and src can turn any element into an image.


HTML5 has so far not taken this approach - elements generally remain  
distinct, and new behaviors and semantics appear in the form of new  
elements.



In my opinion, it is usually better to put primary semantics on  
elements rather than attributes. Here are a few reasons, in  
approximate decreasing order of importance:


- An element is generally seen as a separate thing in itself, whereas  
an attribute is just an attribute. So it is natural to think of an  
element having more semantic strength than an attribute.


- Semantics that has associated behavior often has an associated DOM  
API. For example, the A element has a number of attributes related to  
its use as a hyperlink source, to programmatically retrieve or change  
only part of the href URI. If any element could have the href  
attribute, the options become omitting the API, adding it to all  
elements, or (yuck) making it conditionally present on all elements  
based on presence or absence of the attribute.


- It's easier (and, in many implementations, more efficient) to style  
by tag name rather than by presence or absence of an attribute.


- Typically, browser implementations have an implementation class per  
element, but not a class per attribute, so putting primary semantics  
and behavior on an element instead of an attribute promotes clean  
implementation. Otherwise, all behavior ends up in the HTMLElement  
base class.



Finally, I'd like to conclude with this reductio ad absurdum of the  
XHTML2 approach. If assigning behavior and semantics to attributes is  
so much better, why not just have a single  element:


My cat is really cute: src="mycat.jpeg">picture of my cat. Check out href="story.html">this hilarious story  
about her.


I find the HTML approach much more readable and more semantically clear:

My cat is really cute: . Check out this hilarious story  
about her.


Regards,
Maciej