Re: [9front] htmlfs

[hiro <23hiro@gmail.com>]

after writing my last email i googled xpath, and realize that i only
ever got to see a subset of it's insane complexity (the simple path
notation that includes a way to specify this n-th-element of a type,
which i have seen used a lot in practice by adblockers and anything
that needs to scrape content from websites that don't supply
meaningful element names.

contrary, i have indeed seen that some websites randomize their
element names to prevent this kind of javascript-free processing. so
yes, our low effort will not help with websites that really don't want
to be scraped...

On 9/2/21, hiro <23hiro@gmail.com> wrote:
> On 8/31/21, Pavel Renev <an2qzavok@gmail.com> wrote:
>> I have a half-backed DOMfs:
>> http://git.nsmpr.xyz/domfs/files.html
>> but it just represents documents as a flat list of numbered nodes (the
>> way
>> rio serves its windows) and their hierarchy is provided through a
>> separate
>> file.
>>
>> The challenge with xml/html is that unlike traditional file trees their
>> elements do not have unique names and instead addressed by their order.
>> Additionaly, element's attributes often play bigger role than text data
>> they
>> contain.
>> Style also can override tree hierarchy when it comes to rendering, and
>> when
>> it comes to javascript, programs look up needed elements via global
>> search
>> by id and usually only care about element's immediate parent/children.
>>
>> TL;DR: the tree is a lie.
>> Maybe serving html via some kind of database query interface would be
>> better.
>>
>
> why not do like xpath? numbers can signify order.
> we don't support javascript anyway, so the tree wouldn't really change
> under our feet...
>