headers
Karl Dubost | 1 Sep 2008 05:20
Picon
Favicon

Re: Creative Commons Rights Expression Language


Le 29 août 2008 à 23:04, Henri Sivonen a écrit :
> Also, having more metadata leads to UI clutter and data entry  
> fatigue that alienates users. In the past, I worked on a content  
> repository project that failed because (among other things) the  
> content upload UI asked for an insane amount (a couple of screenfuls  
> back then; probably a screenful today) of metadata when it didn't  
> occur to system specifiers to invest in full text search. More  
> metadata isn't better. Instead, systems should ask for the least  
> amount of metadata that can possibly work (when the metadata must be  
> entered by humans as opposed to being captured by machines like EXIF  
> data). See also
> http://www.w3.org/QA/2008/08/the-digital-stakhanovite

hehe. This was a-good-try-but-mischaracterization-from-the-ministry-of- 
truth to associate this article with the rants on metadata :) Let's  
clarify.

What I explain in the article is not the volume of metadata, but the  
volume of items and the context of usage.

    1. Extract anything you can from the data itself (exif, iptc, xmp,  
modifications, date)
    2. Give a possibility in the UI to modify or add data.

In a business environment, you might have to give metadata about a  
work. I do it in my every day job. I give titles to my emails, I put  
comments in my cvs commits, etc. etc. These are all constraints. Not  
adding the data would still work technically.
(Continue reading)

Permalink | Reply | 2 comments |
headers
Biju Gm@il | 1 Sep 2008 06:18
Picon

Re: In correct HTML 5 tutorials

Per http://www.w3schools.com/about/about_refsnes.asp
I see Ståle Refsnes as author of said tutorial.
So let me forward this mail to them.

http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2008-August/016159.html
subscribe to list at http://lists.whatwg.org/listinfo.cgi/whatwg-whatwg.org

On Sun, Aug 31, 2008 at 4:00 AM, Ian Hickson <ian@...> wrote:
> On Sat, 30 Aug 2008, Biju Gm <at> il wrote:
>>
>> http://www.w3schools.com/ is a very popular tutorial site. They have
>> already started tutorials for HTML5
>> http://www.w3schools.com/tags/html5.asp
>>
>> I see errors
>> at http://www.w3schools.com/tags/html5_video.asp
>> and http://www.w3schools.com/tags/html5_audio.asp
>>
>> autoplay ==> true | false
>> controls ==> true | false
>>
>> As far as I know autoplay="false"
>> also means enable autoplay in firefox.
>>
>> I wish somebody contact them to correct those and other errors.
>
> Please do so! :-)
>
> I encourage you to contact this site as well as any others and point out
> any mistakes you see. I think it's great that tutorials are starting to
(Continue reading)

Permalink | Reply | 0 comments |
headers
Henri Sivonen | 1 Sep 2008 09:17
Picon
Picon
Favicon

Re: Creative Commons Rights Expression Language

On Sep 1, 2008, at 06:20, Karl Dubost wrote:

> Le 29 août 2008 à 23:04, Henri Sivonen a écrit :
>> Also, having more metadata leads to UI clutter and data entry  
>> fatigue that alienates users. In the past, I worked on a content  
>> repository project that failed because (among other things) the  
>> content upload UI asked for an insane amount (a couple of  
>> screenfuls back then; probably a screenful today) of metadata when  
>> it didn't occur to system specifiers to invest in full text search.  
>> More metadata isn't better. Instead, systems should ask for the  
>> least amount of metadata that can possibly work (when the metadata  
>> must be entered by humans as opposed to being captured by machines  
>> like EXIF data). See also
>> http://www.w3.org/QA/2008/08/the-digital-stakhanovite
>
> hehe. This was a-good-try-but-mischaracterization-from-the-ministry- 
> of-truth

That was uncalled for.

> to associate this article with the rants on metadata :) Let's clarify.

It's an excellent article. Thank you for writing it.

> What I explain in the article is not the volume of metadata, but the  
> volume of items and the context of usage.
>
>   1. Extract anything you can from the data itself (exif, iptc, xmp,  
> modifications, date)
(Continue reading)

Permalink | Reply | 0 comments |
headers
ddailey | 1 Sep 2008 13:04

Re: Creative Commons Rights Expression Language

Sorry for joining in naively to a conversation I've not been following, but 
reading Karl's remarks on the facilitation of metadata entry for users, some 
discussions in the vicinity of the recent SVGOpen that concerned usability, 
accessibility,  and metadata made me think the following (that I suppose is 
rather outside the realm of HTML):

Suppose the user or author (since in an app the distinction is blurred 
somewhat) is building something like a graph (in the discrete math sense), 
an image repository, or even a diagram (though the categories of content 
here are heterogeneous, making the argument a bit more tenuous) using a 
guiwebapp (like inkscape for diagrams or 
http://srufaculty.sru.edu/david.dailey/svg/graphs30.svg for graphs). Let's 
say there are n basic entities (like graphs or images) for which metadata is 
required. Let us furthermore assume the metadata description language is of 
order 0 1 2 3  or 4 * and that the minimum number of user operations 
required to complete the metadata description for a single entity is bounded 
above by k.

We then may plot a user performance function that estimates the probability, 
p,  that users will actually succeed in entering data (as a function perhaps 
of not only n and k, but of the user's investment in the process). Clearly 
as n and k grow and as the user's investment in the process declines, so 
does p. We are interested, through, interface, in maximizing p.

I have a hunch (in math it is called a conjecture, but in CHI it is more 
like a hunch) that not only how, but also when, this conversation between 
user and software takes place affects the probability. For example if an 
artist were using Inkscape to draw SVG, then mandating a conversation about 
metadata each time a curve or gradient is completed is likely to drive users 
to AutoCad for their diagrams, even if wine is served.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Ian Hickson | 2 Sep 2008 05:38
Picon

Re: [editorial] Tokeniser "tag name" state order

On Tue, 17 Jun 2008, Andrew Sidwell wrote:
>
> http://www.whatwg.org/specs/web-apps/current-work/multipage/tokenisation.html#tag-name0
> 
> The "tag name" state has the "EOF" entry in a weird place -- in other 
> states, "EOF" comes before "Anything else", but in this one it comes 
> between "U+0041 LATIN CAPITAL LETTER A through to U+005A LATIN CAPITAL 
> LETTER Z" and "U+002F SOLIDUS (/)".  Putting it in the same place as it 
> is in other states would be nice.

Fixed.

--

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'
Permalink | Reply | 0 comments |
headers
Ian Hickson | 2 Sep 2008 05:48
Picon

Re: vtab as an NCR expansion

On Wed, 18 Jun 2008, Henri Sivonen wrote:
>
> Is it intentional that the vtab change didn't cause a change to vtab 
> treatment when expanding NCRs?

Yes; why would it cause a change? The character still passes through, it's 
just not treated as whitespace. (It's not like U+000D, which is converted 
to U+000A.)

--

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'
Permalink | Reply | 2 comments |
headers
Ian Hickson | 2 Sep 2008 05:50
Picon

Re: Any "other" end tag in after head

On Wed, 18 Jun 2008, Henri Sivonen wrote:
>
> After head talks about any "other" end tag, but has no definitions for 
> end tags but "other". Is that intentional?

It was, for consistency, but I've changed it.

--

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'
Permalink | Reply | 0 comments |
headers
Ian Hickson | 2 Sep 2008 06:04
Picon

Comment parsing


Included below are some e-mails regarding how to parse comments. They 
point out inconsistencies between browsers and the spec. These 
inconsistencies were known when the spec was written. Browsers aren't 
consistent with each other either. I'd rather leave the parser spec stable 
here for a while to see if we can converge on that (as far as I can tell 
it represents a good compromise along the axes of compatibility, security, 
implementation ease, and maintainability).

If browsers, when they implement HTML5, find that they cannot get good 
enough compatibility with the current spec text, then we should change the 
spec at that point.

On Thu, 26 Jun 2008, Adam Barth wrote:
>
> Recently, I've been testing how browser parsers handle unterminated <!-- 
> comments -->.  Internet Explorer 7, Firefox 3, Safari 3.1, and Opera 9.5 
> agree on the following cases:
> 
> http://crypto.stanford.edu/~abarth/research/html5/comments/open-textarea.html 
> http://crypto.stanford.edu/~abarth/research/html5/comments/open-script.html 
> http://crypto.stanford.edu/~abarth/research/html5/comments/open-style.html
> 
> Essentially, they treat the <!-- as if it did not start a comment. Ian 
> pointed out on IRC that this might be a security vulnerability because 
> the result of parsing the stream depends on whether the parser hung or 
> terminated at the end of the stream.  (If the parser had hung, it would 
> be awaiting more characters for the comment.)
> 
> The above browsers almost agree for on the behavior for <title>:
(Continue reading)

Permalink | Reply | 0 comments |
headers
Ian Hickson | 2 Sep 2008 06:36
Picon

Re: Define Authoring Requirements for Duplicate Attributes

On Fri, 4 Jul 2008, Lachlan Hunt wrote:
>
>   In the Writing HTML Documents section, under Attributes, the spec 
> should state that attribute names need to be unique for each element, 
> and that duplicate attributes are an error.  Currently, this is only 
> stated in the parsing algorithm.

I've tried to fix this. It's complicated by the serialisation of non-HTML 
element attributes.

--

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'
Permalink | Reply | 0 comments |
headers
Ian Hickson | 2 Sep 2008 07:06
Picon

Re: Superset encodings [Re: ISO-8859-* and the C1 control range]

On Wed, 30 Jul 2008, Øistein E. Andersen wrote:
> 
> The current table seems to cover the mappings between different common 
> compatible 8-bit encodings as implemented in IE7, yes.  The table at 
> <http://coq.no/character-tables/mime/en> gives a bit more detail, most 
> of which is better kept outside HTML5 itself. However, the following 
> observations can be made:
> 
> 1.  Opera, Firefox and Safari all handle US-ASCII as Windows-1252.
>     IE7, on the other hand, simply ignores the high bit (as it does for
>     a few other 7-bit encodings, by the way).  Perhaps this
>     alias could be dropped from the other browsers.

Ignoring the high bit seems like a dangerous security bug; dropping any 
character with a high bit as U+FFFD seems unnecessarily drastic. I've made 
the spec go with the O/F/S behaviour here.

> 2.  Firefox and Opera seem to sniff for text/plain; charset=ISO-8859-1 (as per HTML5),
>     whereas Safari seems to do the same for text/plain; charset=ISO-8859-11
>     instead [Version 3.1.2 (5525.20.1)].  Bug?

I believe so.

> 3.  For certain character sets, different browsers map to different, but visually
>     similar Unicode characters.  Sometimes, one mapping is old/outdated,
>     but this is not always the case.

Not sure what I can do about that.

> 4.  Delete (0x7F) and the C1 range (0x80--0x9F) are handled quite inconsistently;
(Continue reading)

Permalink | Reply | 2 comments |

Gmane