DOM spec input wanted: Can we do without explicit link types?

List overview All Threads
Download

newer

older

Re: [Wikitext-l] Persoid with...

Problems installing Parsoid

Gabriel Wicke

8 Jan 2014 8 Jan '14

8:37 p.m.

Hi, I'd like to ask you for your input on a change to the DOM spec [1] we are considering. The idea is to simplify links by removing the explicit mw:WikiLink or mw:ExtLink typeof attributes: <a rel="mw:WikiLink" href="./Main_Page">Main Page</a> <a rel="mw:ExtLink" href="http://example.com">http://example.com</a> would become just <a href="Main_Page">Main Page</a> <a href="http://example.com">http://example.com</a> Reasons for this change are: - The external vs. internal link distinction is pretty simple to do with a prefix match on the href. - When editing, an internal link can turn into an external one and vice-versa. Editors should not have to deal with updating the typeof to reflect the information already available in the href attribute. - The page source will be slightly cleaner and smaller. Potential disadvantages we see are - For ISBN links [2], we will continue to link to Special:BookSources, which looks internal. Matching on that to identify ISBN links should however not be harder than it is right now. Are you currently relying on these typeofs? Do you see other issues with this proposed change? Thanks for your input, Gabriel [1]: https://www.mediawiki.org/wiki/Parsoid/MediaWiki_DOM_spec#Wiki_links

Show replies by date

Emmanuel Engelhart

8 Jan 8 Jan

9:29 p.m.

New subject: DOM spec input wanted: Can we do without explicit link types?

Hi Gabriel Le 08/01/2014 21:37, Gabriel Wicke a écrit :

...

I'd like to ask you for your input on a change to the DOM spec [1] we are considering. The idea is to simplify links by removing the explicit mw:WikiLink or mw:ExtLink typeof attributes: <a rel="mw:WikiLink" href="./Main_Page">Main Page</a> <a rel="mw:ExtLink" href="http://example.com">http://example.com</a> would become just <a href="Main_Page">Main Page</a> <a href="http://example.com">http://example.com</a> Reasons for this change are: - The external vs. internal link distinction is pretty simple to do with a prefix match on the href. - When editing, an internal link can turn into an external one and vice-versa. Editors should not have to deal with updating the typeof to reflect the information already available in the href attribute. - The page source will be slightly cleaner and smaller. Potential disadvantages we see are - For ISBN links [2], we will continue to link to Special:BookSources, which looks internal. Matching on that to identify ISBN links should however not be harder than it is right now. Are you currently relying on these typeofs? Do you see other issues with this proposed change?

I rely on this information (the "rel" attribute) and this looks to me like a not so elegant move. Not clean and not robust, because what we will have to build (to identify an external link) a not so easy to maintain heuristic. I fully understand the need to build an efficient solution, I have myself an old computer, but wouldn't that be a compromise to shorten "mw:WikiLink" and "mw:ExtLink". Removing "./" in the href value makes really sense to me. Emmanuel -- Kiwix - Wikipedia Offline & more * Web: http://www.kiwix.org * Twitter: https://twitter.com/KiwixOffline * more: http://www.kiwix.org/wiki/Communication

Gabriel Wicke

10:56 p.m.

New subject: DOM spec input wanted: Can we do without explicit link types?

On 01/08/2014 01:29 PM, Emmanuel Engelhart wrote:

...

Not clean and not robust, because what we will have to build (to identify an external link) a not so easy to maintain heuristic.

The good news is that removal of ./ also entails percent-encoding literal colons in internal links to avoid them being interpreted as protocols. That in turn makes matching for external links pretty simple: /^[a-zA-Z]+:/ No need for an explicit list of protocols there. Gabriel

Emmanuel Engelhart

11:10 p.m.

New subject: DOM spec input wanted: Can we do without explicit link types?

Le 08/01/2014 23:56, Gabriel Wicke a écrit :

...

On 01/08/2014 01:29 PM, Emmanuel Engelhart wrote:

Not clean and not robust, because what we will have to build (to identify an external link) a not so easy to maintain heuristic.

This looks good indeed (and is easy to maintain), but still an heuristic isn't it? In the worst case we will have titles matching this regexp. -- Kiwix - Wikipedia Offline & more * Web: http://www.kiwix.org * Twitter: https://twitter.com/KiwixOffline * more: http://www.kiwix.org/wiki/Communication

Gabriel Wicke

11:14 p.m.

New subject: DOM spec input wanted: Can we do without explicit link types?

On 01/08/2014 03:10 PM, Emmanuel Engelhart wrote:

...

Le 08/01/2014 23:56, Gabriel Wicke a écrit :

On 01/08/2014 01:29 PM, Emmanuel Engelhart wrote:

Not clean and not robust, because what we will have to build (to identify an external link) a not so easy to maintain heuristic.

This looks good indeed (and is easy to maintain), but still an heuristic isn't it? In the worst case we will have titles matching this regexp.

Titles can't match this regexp after this change as we'll percent-encode all literal colons to avoid clients interpreting them as protocols. That was the reason why we added the ./ in the first place, but the idea now is making all links relative to the wiki root rather than the current page name. Main reason for this is that we don't want to rewrite HTML on page rename or when combining HTML from different pages. Gabriel

Emmanuel Engelhart

11:30 p.m.

New subject: DOM spec input wanted: Can we do without explicit link types?

Le 09/01/2014 00:14, Gabriel Wicke a écrit :

...

On 01/08/2014 03:10 PM, Emmanuel Engelhart wrote:

Le 08/01/2014 23:56, Gabriel Wicke a écrit :

On 01/08/2014 01:29 PM, Emmanuel Engelhart wrote:

Not clean and not robust, because what we will have to build (to identify an external link) a not so easy to maintain heuristic.

This looks good indeed (and is easy to maintain), but still an heuristic isn't it? In the worst case we will have titles matching this regexp.

Jiang BIAN

12 Jan 12 Jan

10:16 a.m.

New subject: DOM spec input wanted: Can we do without explicit link types?

Hi Gabriel, I noticed the spec hasn't been updated yet (will you do that once the change is checked in?) And could you also document that the "post-processing" will be available for clients that need "elaborated" information? (maybe via an additional API or put an additional cgi parameters, those information can be easily gotten them back) In general, I think keeping more raw information is a way to provide more development flexibility for clients. Thanks On Wed, Jan 8, 2014 at 3:30 PM, Emmanuel Engelhart <kelson(a)kiwix.org> wrote:

...

Le 09/01/2014 00:14, Gabriel Wicke a écrit :

On 01/08/2014 03:10 PM, Emmanuel Engelhart wrote: > Le 08/01/2014 23:56, Gabriel Wicke a écrit : >> On 01/08/2014 01:29 PM, Emmanuel Engelhart wrote: >>> Not clean and not robust, because what we will have to build (to >>> identify an external link) a not so easy to maintain heuristic. >> >> The good news is that removal of ./ also entails percent-encoding >> literal colons in internal links to avoid them being interpreted as >> protocols. That in turn makes matching for external links pretty

simple:

/^[a-zA-Z]+:/

This looks good indeed (and is easy to maintain), but still an heuristic isn't it? In the worst case we will have titles matching this regexp.

Then OK to me for this move, we have elegant solutions to replace the current ones. Thank you very much for having asked/warned people about this. Emmanuel -- Kiwix - Wikipedia Offline & more * Web: http://www.kiwix.org * Twitter: https://twitter.com/KiwixOffline * more: http://www.kiwix.org/wiki/Communication _______________________________________________ Wikitext-l mailing list Wikitext-l(a)lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitext-l

-- Jiang BIAN This email may be confidential or privileged. If you received this communication by mistake, please don't forward it to anyone else, please erase all copies and attachments, and please let me know that it went to the wrong person. Thanks.

Gabriel Wicke

13 Jan 13 Jan

6:22 p.m.

New subject: DOM spec input wanted: Can we do without explicit link types?

On 01/12/2014 02:16 AM, Jiang BIAN wrote:

...

Hi Gabriel, I noticed the spec hasn't been updated yet (will you do that once the change is checked in?)

Yes, I was asking here in advance so that it can inform our discussion.

...

And could you also document that the "post-processing" will be available for clients that need "elaborated" information? (maybe via an additional API or put an additional cgi parameters, those information can be easily gotten them back)

We'll document the code needed to distinguish external from internal links [1], and will also add documentation for the URL bases of RFC/PMID/ISBN links. The latter is already needed with the current spec. Both encodings provide the same information. In the current spec the external vs. internal distinction is encoded redundantly in two attributes (rel and href), while the proposal is to encode this in the href attribute only. Gabriel [1]: var isExternal = /^[a-zA-Z]+:/.test(href)

Inez Korczyński

8 Jan 8 Jan

10:24 p.m.

New subject: DOM spec input wanted: Can we do without explicit link types?

At this moment VisualEditor depends on rel attribute to identify type of the link. Not having rel attribute wouldn't make things easier in VisualEditor when converting from internal to external (or other way round) since it requires replacing internal type of the annotation anyways. I don't like that consumer of HTMLDOM would have to know certain rules (starts with http or Special:BookSources) in order to recognize type of the element. Inez On Wed, Jan 8, 2014 at 12:37 PM, Gabriel Wicke <gwicke(a)wikimedia.org> wrote:

...

C. Scott Ananian

10:32 p.m.

New subject: DOM spec input wanted: Can we do without explicit link types?

On Wed, Jan 8, 2014 at 5:24 PM, Inez Korczyński <inez(a)wikia-inc.com> wrote:

...

I don't like that consumer of HTMLDOM would have to know certain rules (starts with http or Special:BookSources) in order to recognize type of the element.

Note that they need to know special rules already, in order to properly identify interwiki links, PMID, RFC, ISBN, external links, etc. So the alternative to this proposal is really to add *more* rel types, past just mw:ExtLink and mw:WikiLink. The current situation is the worst of both worlds -- we don't provide enough information to accurately identify the link type without examining the URL, but we also require some arbitrary distinction to be made in the rel attribute. --scott -- (http://cscott.net)

Emmanuel Engelhart

10:36 p.m.

New subject: DOM spec input wanted: Can we do without explicit link types?

Le 08/01/2014 23:32, C. Scott Ananian a écrit :

...

The current situation is the worst of both worlds -- we don't provide enough information to accurately identify the link type without examining the URL, but we also require some arbitrary distinction to be made in the rel attribute.

C. Scott Ananian

10:52 p.m.

New subject: DOM spec input wanted: Can we do without explicit link types?

One option here is to get serious about the 'post processing' stage of parsoid. The goal was to have a stripped down HTML-based representation for MW content. But many applications (kwix, pdf rendering, etc) want some additional "sugar" in the HTML. They would like, say, more precise link types, or alt and title tags on images, or redlink information. I believe gwicke's original plan was to have a post processing pipeline where this could be added. Perhaps some of that postprocessing could optionally take place within the parsoid codebase. If you requested "elaborated html" from parsoid, it could go through and add some extra attributes and rel types. Would that sort of design satisfy your needs, Emmanuel (and allow us to remove the rel attribute in the core representation)? --scott On Wed, Jan 8, 2014 at 5:36 PM, Emmanuel Engelhart <kelson(a)kiwix.org> wrote:

...

Le 08/01/2014 23:32, C. Scott Ananian a écrit :

Yes, I'm not against more information. Emmanuel -- Kiwix - Wikipedia Offline & more * Web: http://www.kiwix.org * Twitter: https://twitter.com/KiwixOffline * more: http://www.kiwix.org/wiki/Communication _______________________________________________ Wikitext-l mailing list Wikitext-l(a)lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitext-l

-- (http://cscott.net)

Emmanuel Engelhart

11:05 p.m.

New subject: DOM spec input wanted: Can we do without explicit link types?

Le 08/01/2014 23:52, C. Scott Ananian a écrit :

...

If this is possible to offer both, like you propose, without generating too much additional work, then this looks to me to be an excellent proposition. Emmanuel -- Kiwix - Wikipedia Offline & more * Web: http://www.kiwix.org * Twitter: https://twitter.com/KiwixOffline * more: http://www.kiwix.org/wiki/Communication

Gabriel Wicke

11:08 p.m.

New subject: DOM spec input wanted: Can we do without explicit link types?

On 01/08/2014 03:05 PM, Emmanuel Engelhart wrote:

...

Perhaps some of that postprocessing could optionally take place within the parsoid codebase. If you requested "elaborated html" from parsoid, it could go through and add some extra attributes and rel types. Would that sort of design satisfy your needs, Emmanuel (and allow us to remove the rel attribute in the core representation)?

If this is possible to offer both, like you propose, without generating too much additional work, then this looks to me to be an excellent proposition.

Instead of a heavy-weight postprocessor we can also just provide the code that classifies a href into different types. It is a pretty simple method, unlikely longer than a few lines. Gabriel

3779

days inactive

3784

days old

wikitext-l@lists.wikimedia.org

Manage subscription

13 comments

5 participants

tags (0)

participants (5)

C. Scott Ananian
Emmanuel Engelhart
Gabriel Wicke
Inez Korczyński
Jiang BIAN