Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

A simpler DOM in JS

160 views
Skip to first unread message

Michael Haufe (TNO)

unread,
Feb 3, 2018, 5:24:27 PM2/3/18
to
I'm not a fan of JSX, nor was I a fan of E4X before it. Embedded DSLs require code-switching [1] for understanding, or require the DSL to be a black box to the host language in the case of template strings [2].

Dealing with the DOM APIs directly are terribly verbose though as we know. Should we not do better?

In System.XML.LINQ [3] the approach is to construct XML elements and their contents by nested constructors:

<script type="C#">
var root = new XElement("Root",
new XElement("Child1", 1),
new XElement("Child2", 2),
new XElement("Child3", 3),
new XElement("Child4", 4),
new XElement("Child5", 5),
new XElement("Child6", 6)
);

Console.WriteLine(root);

/*
<Root>
<Child1>1</Child1>
<Child2>2</Child2>
<Child3>3</Child3>
<Child4>4</Child4>
<Child5>5</Child5>
<Child6>6</Child6>
</Root>
*/
</script>

Should we not do similar for the dirty DOM we have to deal with? Here's what we have to contend with for the equivalent:

<script type="JavaScript">
var root = document.createElement("root")

for(var i = 1; i <= 6; i++) {
var child = document.createElement("child" + i)
child.textContent = i
root.appendChild(child)
}

console.log(root.outerHTML)
</script>

And that is for a very trivial use-case.

My proposal is that a library be created to promote the approach of System.XML.LINQ to the HTML DOM. The result being not simply the emulation of the C# example but additionally the ability to warn of deprecated attribute usage and illegal compositions such as placing a button element inside of an option element.

I am curious to the community's thoughts on the topic.


[1] <https://en.wikipedia.org/wiki/Code-switching>
[2] <http://2ality.com/2015/01/template-strings-html.html>
[3] <https://msdn.microsoft.com/en-us/library/system.xml.linq.xelement(v=vs.110).aspx>

Martin Honnen

unread,
Feb 4, 2018, 8:26:59 AM2/4/18
to
But why whould a HTML DOM allow you to create elements named "Root" or
"Child1" at all? An odd example at least.

And the LINQ object model has at least one flaw with its lack of
representation of prefixes in XName that makes lexical representations
of trees dependent on the implementation strategy to choose prefixes e.g.

XNamespace xhtml = "http://www.w3.org/1999/xhtml";

XElement html = new XElement(xhtml + "html",
new XElement(xhtml + "body",
new XElement(xhtml + "p", "This is a test.")));

Console.WriteLine(html);

outputs

<html xmlns="http://www.w3.org/1999/xhtml">
<body>
<p>This is a test.</p>
</body>
</html>

and if we add a namespace declaration attribute and output the tree again

html.Add(new XAttribute(XNamespace.Xmlns + "xhtml", xhtml));

Console.WriteLine(html);

we now get

<xhtml:html xmlns:xhtml="http://www.w3.org/1999/xhtml">
<xhtml:body>
<xhtml:p>This is a test.</xhtml:p>
</xhtml:body>
</xhtml:html>

so suddenly all the generated qualified names of the elements have that
prefix.

I agree the W3C DOM is ugly, in particular with all those different
levels it has and the whole factory based approach and I am glad to have
class based alternatives like XOM or JDOM in the Java world or XLINQ in
the .NET world.

But part of the power of XLINQ (both for composition (your initial
example could be shortened to

var root = new XElement("Root",
from i in Enumerable.Range(1, 6) select new XElement("Child" + i, i)
);

) and for querying of trees) is due to the integration with LINQ and not
solely based on its node creation API using constructors instead of
factory methods.

I liked E4X and I think it would have worked had there been a DOM
integration but as far as I remember that never happened.

Whether browser-side JS needs another library based API for node
creation I am not sure, it looks like most people are happy with
throwing there string fragments into JQuery.



Julio Di Egidio

unread,
Feb 4, 2018, 9:18:23 AM2/4/18
to
On Sunday, 4 February 2018 14:26:59 UTC+1, Martin Honnen wrote:
> On 03.02.2018 23:24, Michael Haufe (TNO) wrote:
>
> > Dealing with the DOM APIs directly are terribly verbose though as we know. Should we not do better?
> >
> > In System.XML.LINQ [3] the approach is to construct XML elements and their contents by nested constructors:
> >
> > <script type="C#">
> > var root = new XElement("Root",
> > new XElement("Child1", 1),
<snip>
> Whether browser-side JS needs another library based API for node
> creation I am not sure, it looks like most people are happy with
> throwing there string fragments into JQuery.

Or use something like React, the accomplished apotheosis of the layering fuck
up...

Julio

Thomas 'PointedEars' Lahn

unread,
Feb 4, 2018, 11:51:04 PM2/4/18
to
Michael Haufe (TNO) wrote:

> I'm not a fan of JSX, nor was I a fan of E4X before it.

E4X would have made building trees a lot easier, but it had flaws.

> […]
<https://github.com/PointedEars/JSX/blob/27be459b2da4d2b8052c293d6930d0c020821de4/dom.js#L504-L663>

(The name “JSX” is coincidental; I used it first, but only the people in
Usenet, SELFHTML.DE, and maybe Twitter, knew about it.)

> Here's what we have to contend with for the equivalent:
>
> <script type="JavaScript">

Not Valid.

> var root = document.createElement("root")
>
> for(var i = 1; i <= 6; i++) {
> var child = document.createElement("child" + i)
> child.textContent = i
> root.appendChild(child)
> }

var root = jsx.dom.createNodeFromObj({
type: "root",
childNodes: Array.apply(null, {length: 6}).map(
(e, i) => {
return {
type: "child" + i,
properties: {textContent: i}
};
})
});

> console.log(root.outerHTML)

Tested on <http://PointedEars.de/>, which uses JSX:dom.js.

[<child$i>…</…> is insane markup.]

> [tl;dr]

--
PointedEars
FAQ: <http://PointedEars.de/faq> | <http://PointedEars.de/es-matrix>
<https://github.com/PointedEars> | <http://PointedEars.de/wsvn/>
Twitter: @PointedEars2 | Please do not cc me./Bitte keine Kopien per E-Mail.

Thomas 'PointedEars' Lahn

unread,
Feb 5, 2018, 12:15:25 AM2/5/18
to
Martin Honnen wrote:

> I liked E4X and I think it would have worked

ACK.

> had there been a DOM integration but as far as I remember that never
> happened.

According to the ECMAScript Support Matrix, Firefox 1.6 to 20 had E4X
support, i.e. before that died the Mozilla.com death. It is a guess,
but the argument was probably the same old fallacy: “Nobody uses it.”

> Whether browser-side JS needs another library based API for node
> creation I am not sure, it looks like most people are happy with
> throwing there string fragments into JQuery.

Implementing Emmet would be a good idea, too, but given support in Atom
(currently, emmet 2.4.3), somebody probably has already done it in/for
Google V8 JavaScript.

Thomas 'PointedEars' Lahn

unread,
Feb 5, 2018, 12:26:31 AM2/5/18
to
Thomas 'PointedEars' Lahn wrote:

> Michael Haufe (TNO) wrote:
>> var root = document.createElement("root")
>>
>> for(var i = 1; i <= 6; i++) {
>> var child = document.createElement("child" + i)
>> child.textContent = i
>> root.appendChild(child)
>> }
>
> var root = jsx.dom.createNodeFromObj({
> type: "root",
> childNodes: Array.apply(null, {length: 6}).map(
> (e, i) => {
> return {
> type: "child" + i,
> properties: {textContent: i}
> };
> })
> });

Supplemental:

1. Add 1 for equivalence :)

2. Learning Android app development recently (again) has reminded me of
a complementary approach: the possibility to maintain pure layout (XML)
markup and create (widget) object( tree)s from it.

Michael Haufe (TNO)

unread,
Feb 5, 2018, 2:06:59 AM2/5/18
to
Martin Honnen wrote:
> Michael Haufe (TNO) wrote:
>
> But why whould a HTML DOM allow you to create elements named "Root" or
> "Child1" at all? An odd example at least.

Odd yes, but legal [1]

> And the LINQ object model has at least one flaw with its lack of
> representation of prefixes in XName that makes lexical representations
> of trees dependent on the implementation strategy to choose prefixes e.g.
>
> [...]

I agree, the overloading and side effects there are a strange choice.

> I agree the W3C DOM is ugly, in particular with all those different
> levels it has and the whole factory based approach and I am glad to have
> class based alternatives like XOM or JDOM in the Java world or XLINQ in
> the .NET world.

> But part of the power of XLINQ (both for composition (your initial
> example could be shortened to

> var root = new XElement("Root",
> from i in Enumerable.Range(1, 6) select new XElement("Child" + i, i)
> );
>
> ) and for querying of trees) is due to the integration with LINQ and not
> solely based on its node creation API using constructors instead of
> factory methods.

Which we know can be emulated analogously with the new spread operator and Array.from(), and other iterable constructs

> I liked E4X and I think it would have worked had there been a DOM
> integration but as far as I remember that never happened.

Removed primarily due to security and compatibility issues if you recall [2]

> Whether browser-side JS needs another library based API for node
> creation I am not sure, it looks like most people are happy with
> throwing there string fragments into JQuery.

Are you?

[1] <https://html.spec.whatwg.org/multipage/dom.html#htmlunknownelement>
[2] <https://bugzilla.mozilla.org/show_bug.cgi?id=788293>

Michael Haufe (TNO)

unread,
Feb 5, 2018, 2:15:42 AM2/5/18
to
Thomas 'PointedEars' Lahn wrote:
> Martin Honnen wrote:
>
> > I liked E4X and I think it would have worked
>
> ACK.

Besides the SpiderMonkey Engine, I think ActionScript was the only other implementation of it. I don't know what the state is of it there.

> > had there been a DOM integration but as far as I remember that never
> > happened.
>
> According to the ECMAScript Support Matrix, Firefox 1.6 to 20 had E4X
> support, i.e. before that died the Mozilla.com death. It is a guess,
> but the argument was probably the same old fallacy: “Nobody uses it.”

The issue was security primarily [1][2]

[1] <https://bugzilla.mozilla.org/show_bug.cgi?id=788293>
[2] <https://bugzilla.mozilla.org/show_bug.cgi?id=695577>

Michael Haufe (TNO)

unread,
Feb 5, 2018, 2:30:49 AM2/5/18
to
Thomas 'PointedEars' Lahn wrote:
> Michael Haufe (TNO) wrote:
>
> > I'm not a fan of JSX, nor was I a fan of E4X before it.
>
> E4X would have made building trees a lot easier, but it had flaws.

Indeed, as referenced earlier.

> [...]

> <https://github.com/PointedEars/JSX/blob/27be459b2da4d2b8052c293d6930d0c020821de4/dom.js#L504-L663>

> (The name “JSX” is coincidental; I used it first, but only the people in
> Usenet, SELFHTML.DE, and maybe Twitter, knew about it.)

I had forgotten about this as you don't advertise much. Do you have some off-the-cuff examples of usage? And from a quick look, it still holds on to a significant amount of legacy IE management (not a criticism). Is there anything you would change in retrospect at this stage?

> > Here's what we have to contend with for the equivalent:
> >
> > <script type="JavaScript">
>
> Not Valid.

I'm surprised you didn't pick on <script type="C#">.

This was being used for demarcation, not for implying use in some web page.

> > var root = document.createElement("root")
> >
> > for(var i = 1; i <= 6; i++) {
> > var child = document.createElement("child" + i)
> > child.textContent = i
> > root.appendChild(child)
> > }
>
> var root = jsx.dom.createNodeFromObj({
> type: "root",
> childNodes: Array.apply(null, {length: 6}).map(
> (e, i) => {
> return {
> type: "child" + i,
> properties: {textContent: i}
> };
> })
> });
>
> > console.log(root.outerHTML)
>
> Tested on <http://PointedEars.de/>, which uses JSX:dom.js.

Ah, here is the example I was asking for earlier.

> [<child$i>…</…> is insane markup.]
>
> > [tl;dr]

To quote Willy Wonka: "A Little Nonsense Now and Then is Relished by the Wisest Men" [1]

[1] <https://www.youtube.com/watch?v=MS5_cIwzkII>

Michael Haufe (TNO)

unread,
Feb 5, 2018, 2:33:16 AM2/5/18
to
Thomas 'PointedEars' Lahn wrote:

> [...]

> Supplemental:
>
> 1. Add 1 for equivalence :)
>
> 2. Learning Android app development recently (again) has reminded me of
> a complementary approach: the possibility to maintain pure layout (XML)
> markup and create (widget) object( tree)s from it.

The ghost of XSLT+XML come back to haunt us?

Thomas 'PointedEars' Lahn

unread,
Feb 5, 2018, 5:19:26 AM2/5/18
to
You do not know what you are talking about. XSLT rulez (see the FAQ).

But I was not referring to that. Rather, in Android app development, XML
layouts are “inflated” into widget object hierarchies. For example:

@Override
public ArticleViewHolder onCreateViewHolder(ViewGroup viewGroup,
int viewType) {
Context context = viewGroup.getContext();
int layoutIdForListItem = R.layout.selector_list_item;

LayoutInflater inflater = LayoutInflater.from(context);
boolean shouldAttachToParentImmediately = false;

View view = inflater.inflate(layoutIdForListItem, viewGroup,
shouldAttachToParentImmediately);
ArticleViewHolder viewHolder = new ArticleViewHolder(view);

return viewHolder;
}

Then there is a file res/layout/selector_list_item.xml that contains the
layout for a list item. It looks like this:

--------------------------------------------------------------------------
<?xml version="1.0" encoding="utf-8"?>

<LinearLayout xmlns:android="http://schemas.android.com/apk/res/android"
android:orientation="vertical"
android:layout_width="match_parent"
android:layout_height="wrap_content">

<!-- Horizontal linear layout to create a contacts list item -->
<LinearLayout android:orientation="horizontal"
android:layout_width="match_parent"
android:layout_height="80dp"
android:paddingTop="4dp"
android:paddingBottom="4dp"
android:gravity="center_vertical">

<!-- Person icon -->
<ImageView
android:id="@+id/personIcon"
android:layout_width="wrap_content"
android:layout_height="wrap_content"
android:src="@drawable/ic_person"
android:paddingRight="4dp"
android:paddingLeft="4dp"
android:contentDescription="@string/person_icon"/>

<!-- Text views for a person's first and last name -->
<TextView
android:id="@+id/firstName"
android:layout_width="wrap_content"
android:layout_height="wrap_content"
android:textStyle="bold"
android:textSize="24sp"
android:textColor="@android:color/black"
android:text="@string/first"
android:paddingRight="4dp"
android:paddingLeft ="4dp"/>
[…]
</LinearLayout>

<View
android:layout_width="match_parent"
android:layout_height="1dp"
android:background="@android:color/darker_gray"/>

</LinearLayout>
--------------------------------------------------------------------------

IMHO, that approach produces very clean code¹. It could be used in
ECMAScript-based Web applications as well. That is, the *validateable*
markup defines the layout, script code reads the markup and converts it to
description objects, and other script code produces a document fragmnt with
elements having specific behaviors (widgets). The layout in XML allows to
design it with a graphical editor as well (indeed, XSLT could be used to
make SVG out of it) almost independent of the final presentation. The
intermediary step would allow to adapt or entirely build the layout in
script code without having to deal with the details of the DOM.

______
¹ The above can still be improved; it is exercise code where the student
is supposed to replace all hard-coded values with resource references for
achieving a unified layout throughout all “activities” of the app.

Julio Di Egidio

unread,
Feb 5, 2018, 7:16:32 AM2/5/18
to
On Monday, 5 February 2018 11:19:26 UTC+1, Thomas 'PointedEars' Lahn wrote:
> Michael Haufe (TNO) wrote:
<snip>
> > The ghost of XSLT+XML come back to haunt us?
>
> You do not know what you are talking about. XSLT rulez (see the FAQ).

Your utter bullshit isn't any better.

> script code without having to deal with the details of the DOM.

Rather learn and use *Knockout.js*: it's not just a fantastic little tool, it's
(along the lines of) the right architectural approach, indeed the exact opposite
of your upside down fuck ups.

HTH,

Julio

Thomas 'PointedEars' Lahn

unread,
Feb 5, 2018, 1:12:06 PM2/5/18
to
Michael Haufe (TNO) wrote:

> Thomas 'PointedEars' Lahn wrote:
>> [...]
>>
<https://github.com/PointedEars/JSX/blob/27be459b2da4d2b8052c293d6930d0c020821de4/dom.js#L504-L663>
>
>> […] from a quick look, it still holds on to a significant amount of
>> legacy IE management (not a criticism). Is there anything you would
>> change in retrospect at this stage?

Certainly. My code is not set in stone. To what exactly are you referring?

>> > Here's what we have to contend with for the equivalent:
>> >
>> > <script type="JavaScript">
>> Not Valid.
>
> I'm surprised you didn't pick on <script type="C#">.
>
> This was being used for demarcation, not for implying use in some web
> page.

In this *newsgroup* you should have expected *that* to be misunderstood.

Michael Haufe (TNO)

unread,
Feb 5, 2018, 1:23:22 PM2/5/18
to
Thomas 'PointedEars' Lahn wrote:
> Michael Haufe (TNO) wrote:

> > The ghost of XSLT+XML come back to haunt us?
>
> You do not know what you are talking about. XSLT rulez (see the FAQ).

Ha, you don't need to convince me. I've commited XSLT sins in the past for the hell of it: <view-source:http://ht2012.org/index.xml>
While I like the declarative nature, the use of layout containers I find iffy. How you do manage dynamic layouts?

> IMHO, that approach produces very clean code¹. It could be used in
> ECMAScript-based Web applications as well. That is, the *validateable*
> markup defines the layout, script code reads the markup and converts it to
> description objects, and other script code produces a document fragmnt with
> elements having specific behaviors (widgets). The layout in XML allows to
> design it with a graphical editor as well (indeed, XSLT could be used to
> make SVG out of it) almost independent of the final presentation. The
> intermediary step would allow to adapt or entirely build the layout in
> script code without having to deal with the details of the DOM.

Validation the most important aspect IMO. It's a damned shame this was thrown away in HTML5 in preference for hand-wavery:

<https://github.com/validator/validator/issues/251#issuecomment-192209209>

Thomas 'PointedEars' Lahn

unread,
Feb 5, 2018, 1:42:15 PM2/5/18
to
Michael Haufe (TNO) wrote:

> Thomas 'PointedEars' Lahn wrote:
>> Michael Haufe (TNO) wrote:
>> > The ghost of XSLT+XML come back to haunt us?
>> You do not know what you are talking about. XSLT rulez (see the FAQ).
>
> Ha, you don't need to convince me. I've commited XSLT sins in the past for
> the hell of it: <view-source:http://ht2012.org/index.xml>

:)

>> [Android layout XML]
>
> While I like the declarative nature, the use of layout containers I find
> iffy. How you do manage dynamic layouts?

Depends. “Dynamic” as in…?

> Validation the most important aspect IMO. It's a damned shame this was
> thrown away in HTML5 in preference for hand-wavery:
>
> <https://github.com/validator/validator/issues/251#issuecomment-192209209>

Hmmm. HTML5 validation is actually more strict than HTML < 5 validation,
enabled by a grammar that is algorithmic instead of declarative. But this
also makes it more difficult to implement.

XHTML5 is only XML in name as HTML5 is by design and specification the
antithesis to XHTML (unspecified elements and attributes are allowed, the
latter are even encouraged with “data-…” attributes, SVG and MathML can be
embedded without declaration), so I can understand the lack of desire to
specify a schema for it.

Thomas 'PointedEars' Lahn

unread,
Feb 5, 2018, 1:58:13 PM2/5/18
to
Stefan Ram wrote:

> "Michael Haufe (TNO)" <t...@thenewobjective.com> writes:
>>While I like the declarative nature, the use of layout
>>containers I find iffy. How you do manage dynamic layouts?
>
> You can create and configure objects of all widget and
> container classes (which also can be subclassed) directly
> in Java code without the XML approach.

But that is *strongly* recommended *against* as it does not work well (it
would be a PITA to maintain, if it even worked) with different form factors,
display resolutions, and screen modes. Instead, includes and suffixed
resource directories ought be used.

How come that you virtually *always* recommend the *least* recommended
approaches or the ones recommended *against*?


PointedEars, Google Android Dev Challenge Scholarship alumnus
--

Michael Haufe (TNO)

unread,
Feb 7, 2018, 3:51:48 PM2/7/18
to
Thomas 'PointedEars' Lahn wrote:
> Michael Haufe (TNO) wrote:
>
> > Thomas 'PointedEars' Lahn wrote:
> >> [...]
> >> [Android layout XML]
> >
> > While I like the declarative nature, the use of layout containers I find
> > iffy. How you do manage dynamic layouts?
>
> Depends. “Dynamic” as in…?

As in, if I rotate the screen and I want LinearLayout to become RelativeLayout, what do I do?

> Hmmm. HTML5 validation is actually more strict than HTML < 5 validation,
> enabled by a grammar that is algorithmic instead of declarative. But this
> also makes it more difficult to implement.

s/algorithmic/procedural

Thomas 'PointedEars' Lahn

unread,
Feb 7, 2018, 7:46:17 PM2/7/18
to
Stefan Ram wrote:

> "Michael Haufe (TNO)" <t...@thenewobjective.com> writes:
>>As in, if I rotate the screen and I want LinearLayout to
>>become RelativeLayout, what do I do?
>
> One can save XML files into one's project folder like
>
> res/
> layout/
> main.xml (Default layout)
> layout-port/
> main.xml (Specific layout for portrait mode)
> layout-land/
> main.xml (Specific layout for landscape mode)
>
> This will become packed into a kind of archive file, and the
> system will choose the most appropriate layout at runtime.
> When a device is rotated, the whole "Activity" is being
> rebuilt from scratch, so it then can have a new layout.
>
> Of course, you also can achieve similar results with Java alone.

If you want to create a maintenance nightmare, and a slow application that
nobody will like. There is *much* *more* to suffixed resource directories
than screen mode.

RTFM!

Thomas 'PointedEars' Lahn

unread,
Feb 7, 2018, 7:47:44 PM2/7/18
to
Michael Haufe (TNO) wrote:

> Thomas 'PointedEars' Lahn wrote:
>> Michael Haufe (TNO) wrote:
>> > Thomas 'PointedEars' Lahn wrote:
>> >> [...]
>> >> [Android layout XML]
>> >
>> > While I like the declarative nature, the use of layout containers I
>> > find iffy. How you do manage dynamic layouts?
>> Depends. “Dynamic” as in…?
>
> As in, if I rotate the screen and I want LinearLayout to become
> RelativeLayout, what do I do?

Suppose you have res/layout/activity_main.xml that uses LinearLayout, then
create res/layout-land/, copy the XML file there (keep the filename), and in
the copy change LinearLayout to RelativeLayout (but see also
RecyclerView.LayoutManager subclasses, which work better with listings).
Now, that does _not_ mean that you have to maintain all the *content* twice
(or more): you can use *fragments* to include the same content in different
view groups. (In the course we learned to use fragments precisely for
handling landscape mode.)

See also:
<https://developer.android.com/training/basics/supporting-devices/screens.html>
<https://developer.android.com/training/basics/fragments/index.html>

And that is only one of many specializations that you can implement this way
(which I called “suffixed resource directories” before).

[One of them that ought also be mentioned is internationalization, which
(AISB) would be a PITA if you did in in Java code: just create e.g.
res/values-fr/strings.xml for the text that should be displayed when
the user uses the French locale. If you refer to “@string/…” in your
layouts, or use getString(R.string.…) throughout your Java code, then
you may not have to customize anything else (of course, French words
tend to be longer, so maybe it needs layout tweaking, too). You can
give that XML file to your translators, and its structure is very
simple so they do not have to be coders also, as with GNU gettext.
Compare that to language switches in Java code.

<https://developer.android.com/training/basics/supporting-devices/languages.html>]

This also has to do with what I alluded to earlier: As *you* know, if you
have XML, you can easily convert it to *anything* using XSLT (even on the
fly), for example SVG. I do not know how Android Studio 3.0.1 does the
visualization, but it also contains a visual layout editor. If you select
there that you want a specific landscape layout, for example, then it does
what I described above (except the last step), and opens the copy.

[However, if you know in advance that you want displayed properly in
both modes, you should first consider using a layout manager that does
it automatically, such as a ConstraintLayout that uses resources for
the spacing.]

If you are seriously interested in learning Android development, I can
highly recommend taking part in the Google Android Dev Challenge:

<https://eu.udacity.com/course/android-developer-nanodegree-by-google--nd801>

The next Challenge should start in November, but you can start the
nanodegree at any time. If the Challenge is on, and you submit a convincing
rationale (like I did), you might even win the scholarship and do not have
to pay anything for the course and the optional follow-up training that
Google offers exclusively.

>> Hmmm. HTML5 validation is actually more strict than HTML < 5 validation,
>> enabled by a grammar that is algorithmic instead of declarative. But
>> this also makes it more difficult to implement.
>
> s/algorithmic/procedural

To me, procedural includes the concept of subroutines, which need not be the
case with parser algorithms like those for HTML5.

Thomas 'PointedEars' Lahn

unread,
Feb 7, 2018, 8:27:10 PM2/7/18
to
Stefan Ram wrote:

> "Michael Haufe (TNO)" <t...@thenewobjective.com> writes:
>> As in, if I rotate the screen and I want LinearLayout to
>> become RelativeLayout, what do I do?
>
> One can save XML files into one's project folder like
>
> res/
> layout/
> main.xml (Default layout)
> layout-port/
> main.xml (Specific layout for portrait mode)
> layout-land/
> main.xml (Specific layout for landscape mode)

This is nonsense! The directory suffix is supposed to be *more* *specific*
as the suffixed directories are preferred. As a result, if you have all
three of those directories and files, there is *dead* *code* in
layout/main.xml as the screen mode is either “portrait” or “landscape”, and
the default is “portrait”.

<https://developer.android.com/training/basics/supporting-devices/screens.html#create-layouts>

I feel obligated at this point to recommend to everyone to just ignore
everything that Stefan Ram says regarding IT. He is a folk high school¹
teacher² impervious to criticism who has repeatedly demonstrated that he
has no clue what he is talking about, and probably has not worked so
much as one hour in IT. For all the time that I have been reading him
in the German-speaking Usenet (several years now), he has just been
posing; he has never acknowledged any mistake nor engaged in so much as
one discussion to defend his usually ill-advised ideas :-(

_______
¹
<https://en.wikipedia.org/wiki/Folk_high_school#Germany,_Switzerland_and_Austria>

²
You are not required to have any formal education or degree to teach there.
If suffices that you can convince the school administration that you know
what you are talking about. Which is of course a joke as the administration
usually does not understand the topic themselves, and thus cannot make an
informed judgement. As a result, while the education is comparably
inexpensive, you can also find all sorts of crackpots "teaching" there.

[de] <https://www.akademie.de/wissen/freiberufler-an-volkshochschulen>

John G Harris

unread,
Feb 8, 2018, 2:21:56 PM2/8/18
to
On Thu, 08 Feb 2018 02:27:02 +0100, Thomas 'PointedEars' Lahn
<Point...@web.de> wrote:

<snip>
>he has never acknowledged any mistake

Writes the person who insists he cannot be proved wrong just because
the Standard says he's wrong.


<snip>
>You are not required to have any formal education or degree to teach there.
<snip>

Most English universities do not require lecturers, even professors,
to have a PhD. And then there was Michael Faraday.

John

Michael Haufe (TNO)

unread,
Feb 11, 2018, 1:16:50 PM2/11/18
to
Thomas 'PointedEars' Lahn wrote:
> Michael Haufe (TNO) wrote:

> >> […] from a quick look, it still holds on to a significant amount of
> >> legacy IE management (not a criticism). Is there anything you would
> >> change in retrospect at this stage?
>
> Certainly. My code is not set in stone. To what exactly are you referring?

1. ESNext =[compilation]=> ES Target
2. Move IE specific checks and compatibility into a babel plugin [1]
3. npm packaging (which don't have to be published and can be installed directly from a git repo)

> > This was being used for demarcation, not for implying use in some web
> > page.
>
> In this *newsgroup* you should have expected *that* to be misunderstood.

The subtle prejudice of low-expectations I guess

[1] <https://babeljs.io/docs/plugins/#transform-plugins>

Michael Haufe (TNO)

unread,
Feb 11, 2018, 1:27:40 PM2/11/18
to
Thomas 'PointedEars' Lahn wrote:
> Michael Haufe (TNO) wrote:

> > As in, if I rotate the screen and I want LinearLayout to become
> > RelativeLayout, what do I do?
>
> Suppose you have res/layout/activity_main.xml that uses LinearLayout, then
> create res/layout-land/, copy the XML file there (keep the filename), and in
> the copy change LinearLayout to RelativeLayout (but see also
> RecyclerView.LayoutManager subclasses, which work better with listings).
> Now, that does _not_ mean that you have to maintain all the *content* twice
> (or more): you can use *fragments* to include the same content in different
> view groups. (In the course we learned to use fragments precisely for
> handling landscape mode.)

Sounds far worse than what CSS+HTML provides (flex and grid). I know JavaFX supports CSS for layouts, but I can only imagine what a combination of "hbox" and "flex-direction: row" would do...

> [...]

> If you are seriously interested in learning Android development, I can
> highly recommend taking part in the Google Android Dev Challenge:

Afraid not, after building a Scala compiler + implementing 0CFA and friends on top of it, I've been holding off having to touch the environment again for a significant time. Let's call it another form of PTSD...

<https://gist.github.com/mlhaufe/c5cbe38f35c2a7238bd797eebec06418>

Thomas 'PointedEars' Lahn

unread,
Feb 11, 2018, 10:38:35 PM2/11/18
to
Michael Haufe (TNO) wrote:

> Thomas 'PointedEars' Lahn wrote:
>> Michael Haufe (TNO) wrote:
>> > As in, if I rotate the screen and I want LinearLayout to become
>> > RelativeLayout, what do I do?
>> [suffixed resource directories, build layouts from fragments to DRY]
>
> Sounds far worse than what CSS+HTML provides (flex and grid). I know
> JavaFX supports CSS for layouts, but I can only imagine what a combination
> of "hbox" and "flex-direction: row" would do...

You have not thought this through. Flex and Grid are not nearly
as flexible as, e.g., ConstraintLayout. And there are no includes
in HTML (natively).

Thomas 'PointedEars' Lahn

unread,
Feb 11, 2018, 10:48:29 PM2/11/18
to
Michael Haufe (TNO) wrote:

> Thomas 'PointedEars' Lahn wrote:
>> Michael Haufe (TNO) wrote:
>> >> […] from a quick look, it still holds on to a significant amount of
>> >> legacy IE management (not a criticism). Is there anything you would
>> >> change in retrospect at this stage?
>> Certainly. My code is not set in stone. To what exactly are you
>> referring?
>
> 1. ESNext =[compilation]=> ES Target

Probably not. I envision a testing nightmare.

> 2. Move IE specific checks and compatibility into a babel plugin [1]

No thanks, but I have a compatibility infrastructure already.

> 3. npm packaging (which don't have to be published and can be installed
> directly from a git repo)

Yes, I am considering Bower. There are more important tasks first.

>> > This was being used for demarcation, not for implying use in some web
>> > page.
>> In this *newsgroup* you should have expected *that* to be misunderstood.
>
> The subtle prejudice of low-expectations I guess

Not at all. The “script” element was designed to insert code written in the
languages discussed here.

Michael Haufe (TNO)

unread,
Feb 15, 2018, 3:19:32 PM2/15/18
to
Thomas 'PointedEars' Lahn wrote:

> You have not thought this through. Flex and Grid are not nearly
> as flexible as, e.g., ConstraintLayout.

Admittedly. I'll have to spend more time looking at their approach to layout.

> And there are no includes in HTML (natively).

Chrome supports HTML Imports [1], but it's still an open question if it'll be a standard ultimately, and even so that competitors will implement it. Mozilla has expressed they won't [2].

[1] <http://w3c.github.io/webcomponents/spec/imports/>
[2] <https://hacks.mozilla.org/2015/06/the-state-of-web-components/>

Julio Di Egidio

unread,
Feb 15, 2018, 3:44:01 PM2/15/18
to
On Thursday, 15 February 2018 21:19:32 UTC+1, Michael Haufe (TNO) wrote:
> Thomas 'PointedEars' Lahn wrote:
>
> > You have not thought this through. Flex and Grid are not nearly
> > as flexible as, e.g., ConstraintLayout.
>
> Admittedly. I'll have to spend more time looking at their approach to layout.
>
> > And there are no includes in HTML (natively).
>
> Chrome supports HTML Imports [1]

In HTML5, "natively", one can use script elements to embed even content
of type text/html... Knockout.js, just to say, not only (and just to begin
with) eliminate *all* need for DOM manipulation, it also supports HTML5
script-based templates out of the box (even hierarchical templates), which
is anyway just a bit of logic accessing the nodes under the script element.

Julio

Thomas 'PointedEars' Lahn

unread,
Feb 25, 2018, 1:22:52 PM2/25/18
to
Michael Haufe (TNO) wrote:

> Thomas 'PointedEars' Lahn wrote:
>> And there are no includes in HTML (natively).
>
> Chrome supports HTML Imports [1], but it's still an open question if it'll
> be a standard ultimately, and even so that competitors will implement it.
> Mozilla has expressed they won't [2].
>
> [1] <http://w3c.github.io/webcomponents/spec/imports/>
> [2] <https://hacks.mozilla.org/2015/06/the-state-of-web-components/>

The article is old, but in light of it I find it very unfortunate that, even
more so since Mozilla.com was established, apparently we have to put our
hopes in *companies* like Google and Apple instead of organizations like
Mozilla for innovation in Web development.

To Mozilla/Gecko the choice for a feature always appears to be binary – do
or don’t, with a tendency to the latter – while in WebKit and forks, and
browsers that use them, you do find experimental features to play with that
often become standard later.

I was just reading through the old WebKit blog, “Surfin’ Safari”, and
realized with awe how many cool CSS features they introduced that are now
standard or close to becoming one *because they submitted them as proposals
to the W3C*.

Ken Tilton

unread,
Mar 5, 2018, 11:07:12 AM3/5/18
to
On Saturday, February 3, 2018 at 5:24:27 PM UTC-5, Michael Haufe (TNO) wrote:
> I'm not a fan of JSX, nor was I a fan of E4X before it. Embedded DSLs require code-switching [1] for understanding, or require the DSL to be a black box to the host language in the case of template strings [2].
>
> Dealing with the DOM APIs directly are terribly verbose though as we know. Should we not do better?
>
> In System.XML.LINQ [3] the approach is to construct XML elements and their contents by nested constructors:
>
> <script type="C#">
> var root = new XElement("Root",
> new XElement("Child1", 1),
> new XElement("Child2", 2),
> new XElement("Child3", 3),
> new XElement("Child4", 4),
> new XElement("Child5", 5),
> new XElement("Child6", 6)
> );
>
> Console.WriteLine(root);
>
> /*
> <Root>
> <Child1>1</Child1>
> <Child2>2</Child2>
> <Child3>3</Child3>
> <Child4>4</Child4>
> <Child5>5</Child5>
> <Child6>6</Child6>
> </Root>
> */
> </script>
>
> Should we not do similar for the dirty DOM we have to deal with? Here's what we have to contend with for the equivalent:
>
> <script type="JavaScript">
> var root = document.createElement("root")
>
> for(var i = 1; i <= 6; i++) {
> var child = document.createElement("child" + i)
> child.textContent = i
> root.appendChild(child)
> }
>
> console.log(root.outerHTML)
> </script>
>
> And that is for a very trivial use-case.
>
> My proposal is that a library be created to promote the approach of System.XML.LINQ to the HTML DOM. The result being not simply the emulation of the C# example but additionally the ability to warn of deprecated attribute usage and illegal compositions such as placing a button element inside of an option element.
>
> I am curious to the community's thoughts on the topic.
>
>
> [1] <https://en.wikipedia.org/wiki/Code-switching>
> [2] <http://2ality.com/2015/01/template-strings-html.html>
> [3] <https://msdn.microsoft.com/en-us/library/system.xml.linq.xelement(v=vs.110).aspx>

I just wrote up my system, which supports pure JS because, well, it is all JS all the time. A reactive HTML-workalike JS library silently maintains the DOM for us, with point efficiency because it always knows what changed.

The write-up is in the form of a CodePen: https://codepen.io/kennytilton/pen/mXQNYR

hth, kt

Ken Tilton

unread,
Mar 5, 2018, 11:14:27 AM3/5/18
to
On Sunday, February 4, 2018 at 9:18:23 AM UTC-5, Julio Di Egidio wrote:
> On Sunday, 4 February 2018 14:26:59 UTC+1, Martin Honnen wrote:
> > On 03.02.2018 23:24, Michael Haufe (TNO) wrote:
> >
> > > Dealing with the DOM APIs directly are terribly verbose though as we know. Should we not do better?
> > >
> > > In System.XML.LINQ [3] the approach is to construct XML elements and their contents by nested constructors:
> > >
> > > <script type="C#">
> > > var root = new XElement("Root",
> > > new XElement("Child1", 1),
> <snip>
> > Whether browser-side JS needs another library based API for node
> > creation I am not sure, it looks like most people are happy with
> > throwing there string fragments into JQuery.
>
> Or use something like React, the accomplished apotheosis of the layering fuck
> up...
>
> Julio

Had to look up apotheosis, but OMG, yes.

Michael Haufe (TNO)

unread,
Mar 6, 2018, 8:40:24 PM3/6/18
to
Ken Tilton wrote:

> I just wrote up my system, which supports pure JS because, well, it is all JS all the time. A reactive HTML-workalike JS library silently maintains the DOM for us, with point efficiency because it always knows what changed.
>
> The write-up is in the form of a CodePen: https://codepen.io/kennytilton/pen/mXQNYR

With black box DSLs here as well it seems. From your CodePen:

<script>
defcode( 'preface',
"All tag functions have the signature:\n\
<i>tag</i>([<i>HTML attributes</i>, [<i>custom properties</i>,]] <i>children*</i>)\n\
\n\n\
section({class: 'todoapp'},\n\
header({class: 'header'},\n\
h1('todos'))),\n\
\n\
p('The working app will appear here.')");
</script>

Ken Tilton

unread,
Mar 7, 2018, 3:09:58 PM3/7/18
to
No, that defcode/defchat/defbit DSL is just for this elaborate CodePen, ie, nothing to do with the framework per se. In the "Preface" panel I mentioned we would be building an app within an app. The larger app presents panel after panel within the pen, and over time as I elaborated the larger app I found it a bit (but not much) more manageable to cook up that DSL.

Julio Di Egidio

unread,
Mar 8, 2018, 3:43:13 AM3/8/18
to
> Had to look up apotheosis, but OMG, yes.

You too are proposing the approach that I am (strongly) advising against:
so, either I am misunderstanding you, or you should look up "yes" as well.

Julio

Ken Tilton

unread,
Mar 8, 2018, 8:57:48 AM3/8/18
to
I was agreeing that React, while well-meaning, introduced in effect a completely new language (the layering fuck).

You may be midunderstanding me. My goal is to deliver the benefits of React, and more, with a JS HTML API that works so much like HTML a strong graphic designer could handle it. I like to call it an un-framework.

kt

Julio Di Egidio

unread,
Mar 8, 2018, 10:57:10 AM3/8/18
to
On Thursday, 8 March 2018 14:57:48 UTC+1, Ken Tilton wrote:
> On Thursday, March 8, 2018 at 3:43:13 AM UTC-5, Julio Di Egidio wrote:
> > On Monday, 5 March 2018 17:14:27 UTC+1, Ken Tilton wrote:
> > > On Sunday, February 4, 2018 at 9:18:23 AM UTC-5, Julio Di Egidio wrote:
> > <snip>
> > > > Or use something like React, the accomplished apotheosis of the
> > > > layering fuck up...
> > >
> > > Had to look up apotheosis, but OMG, yes.
> >
> > You too are proposing the approach that I am (strongly) advising against:
> > so, either I am misunderstanding you, or you should look up "yes" as well.
>
> I was agreeing that React, while well-meaning, introduced in effect a
> completely new language (the layering fuck).
>
> You may be midunderstanding me. My goal is to deliver the benefits of React,
> and more, with a JS HTML API that works so much like HTML a strong graphic
> designer could handle it. I like to call it an un-framework.

No, it's you misunderstanding me: the "layering fuckup" has to do with the
*inversion* of layers and responsibilities, not with how the single layers
are realized. IOW, it's a point of architecture and logic, not to mention
of allocation of team resources: you guys are reinventing the wheel and are
reinventing it wrong.

Beginners can't layer code and end up with e.g. client-side code generated
from the server, but just the same happens within the client now, between
structure, presentation and logic of pages: while HTML(5)+CSS+JS is already
the wanted solution. And layering is of course everywhere in software and
not only, so the same problem occurs in many places. React is a case in point
of a very clever though utterly wrong solution to a problem that does not even
exist.

Julio
0 new messages